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Acerca de este documento 



En este tutorial pretendemos mostrar el manejo de las herramientas de 
programacion que GNU ha puesto a disposicion de los usuarios en multitud de 
sistemas, y que Apple ha elegido como base para sus herramientas de 
programacion. Estas herramientas incluyen los conocidos comandos gcc y 
gdb. Sin embargo, las herramientas de programacion de GNU son mucho mas 
completas, e incluyen multitud de comandos que vamos a ir comentando a lo 
largo de este tutorial. 

Este documento se centra en la forma de trabajar, y las opciones particulares 
en Mac OS X pero, debido a la interoperatividad de estas aplicaciones, 
lectores acostumbrados a trabajar en otros entornos (como por ejemplo 
Linux, FreeBSD, o incluso Windows) pueden encontrar util este tutorial, ya 
que en su mayorfa las forma de trabajar es la misma. Ademas, hemos 
procurado hacer hincapie en las peculiaridades de las herramientas de GNU 
en Mac OS X, con el fin de facilitar el poder usar este documento para 
trabajar en otros entornos. 

El tutorial asume que el lector conoce al menos el lenguaje C, aunque en 
concreto en tres temas se explica tambien el uso de las GCC para compilar 
aplicaciones C++ y Java. Si el lector no conoce alguno de estos dos ultimos 
lenguajes puede saltarse el correspond iente tema sin perjuicios para poder 
seguir el resto del documento. 

Al acabar este tutorial el lector deberfa de haber aprendido a compilar y 
depurar sus aplicaciones, crear librerfas, medir el rendimiento, e incluso a 
combinar aplicaciones escritas en distintos lenguajes. 

Nota legal 



Este tutorial ha sido escrito por Fernando Lopez Hernandez para 
macprogramadores.org y de acuerdo a las leyes internacionales sobre 
propiedad intelectual, a la Directiva 2001/29/CE del Parlamento Europeo de 
22 de mayo de 2001 y al artfculo 5 de la Ley 22/1987 de 11 de Noviembre de 
Propiedad Intelectual Espahola, el autor prohfbe la publicacion de este 
documento en cualquier otro servidor web, asf como su venta, o difusion en 
cualquier otro medio sin autorizacion previa. 

Sin embargo el autor anima a todos los servidores web a colocar enlaces a 
este documento. El autor tambien anima a cualquier persona interesada en 
conocer las herramientas de GNU a bajarse o imprimirse este tutorial. 

Madrid, Abril del 2006 

Para cualquier aclaracion contacte con: 

f ernando@macprogramadores . org 



Pag 2 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 

Tabla de contenido 



TEMA 1: Introduccion a las herramientas de programacion de GNU 



1. Las GNU Compiler Collection (GCC) 7 

2. Arquitectura del compilador de GNU 8 

2.1. Frontend y backend 8 

2.2. Fases del compilador 8 

3. Comandos disponibles 10 

3.1. Opciones de la Ifnea de comandos 11 

3.2. Variables de entorno 12 

3.3. Empezar a manejar gcc 13 

TEMA 2: Compilando en C 



1. El preprocesador 15 

1.1. Opciones relacionadas con el preprocesador 15 

1.2. Identificadores del preprocesador desde la Ifnea de comandos 16 

1.3. Rutas de los ficheros de cabecera 17 

2. Usando el compilador de C 18 

2.1. Compilar y enlazar codigo fuente C 18 

2.2. Preprocesar y generar codigo ensamblador 19 

2.3. El comando gcc es un driver 20 

2.4. Estandares 22 

2.5. Indicar el lenguaje a utilizar 22 

3. Extensiones al lenguaje C 23 

3.1. Arrays de longitud variable 23 

3.2. Arrays de longitud cero 24 

3.3. Rangos en la sentencia case 25 

3.4. Declarar variables en cualquier punto del programa 26 

3.5. Numeros largos 26 

3.6. Atributos 27 

3.7. Valor de retorno de sentencias compuestas 30 

3.8. Operador condicional con operandos omitidos 31 

3.9. Nombre de funcion como cadena 32 

3.10. Macros con numero variable de argumentos 32 

3.11. El operador typeof 32 

3.12. Uniones anonimas en estructuras 33 

3.13. Casting a un tipo union 34 

4. Warnings 35 

5. Cambiar la version de las GCC 38 

6. Resolucion de problemas 39 



Pag 3 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 



TEMA 3: Crear y usar librerfas 



1. Librerfas de enlace estatico 41 

1.1. Creadon y uso de librerfas de enlace estatico 41 

1.2. La tabla de sfmbolos 43 

1.3. Modificar y borrar elementos de una librerfa 44 

1.4. Juntar modulos 45 

2. Librerfas de enlace dinamico 47 

2.1. Como funcionan las librerfas de enlace dinamico 47 

2.2. Compatibilidad entre versiones 48 

2.3. Creadon y uso de librerfas 51 

2.4. Instalar la librerfa 53 

2.5. Carga de librerfas en tiempo de ejecucion 56 

2.6. Encapsular la funcionalidad 57 

2.7. Inicializacion de una librerfa 62 

2.8. Encontrar sfmbolos importados 64 

2.9. Librerfas C++ 73 

2.10. Codigo dinamico 77 

2.11. Herramientas para ficheros binarios 79 

3. Frameworks 83 

3.1. Anatomfa 84 

3.2. Versionado de los frameworks 86 

3.3. Un framework de ejemplo 87 

3.4. Frameworks privados 93 

3.5. Los umbrella frameworks 94 

TEMA 4: Compilando en C++ 



1. El compilador de C++ 97 

2. Extensiones al lenguaje C++ 99 

2.1. Obtener el nombre de una funcion y metodo 99 

2.2. Los operadores ?>y?< 99 

3. Name mangling 101 

4. Cabeceras precompiladas 102 

5. Un parche para el enlazador 104 

TEMA 5: Compilando en Java 



1. Compilando Java con las GCC 106 

2. Utilidades Java de las GCC 109 



Pag 4 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 



TEMA 6: Combinar distintos lenguajes 



1. Combinar C y C++ Ill 

1.1. Llamar a C desde C++ Ill 

1.2. Llamar a C++ desde C 112 

2. Acceso a C desde Java 114 

2.1. Una clase Java con un metodo nativo 114 

2.2. Tipos de datos en JNI 117 

2.3. Pasar parametros a un metodo nativo 117 

2.4. Acceso a clases Java desde un metodo nativo 118 

TEMA 7: Depuracion, optimizacion y perfilado 



1. Depurar aplicaciones 122 

1.1. Generar codigo depurable 122 

1.2. Cargar un programa en el depurador 122 

1.3. Analisis postmortem de un programa 132 

1.4. Enlazar el depurador con una aplicacion en ejecucion 134 

2. Optimizacion 136 

2.1. Opciones de optimizacion 136 

2.2. Scheduling 137 

2.3. Deshacer bucles 138 

3. Control de corrupcion y perdida de memoria 139 

3.1. Corrupcion de memoria 139 

3.2. Perdida de memoria 140 

3.3. Las malloc tools 141 

3.4. El comando leaks 145 

3.5. El COmando malloc history 147 

3.6. MallocDebug 148 

4. Perfilado 149 

4.1. Usar el profiler gprof 149 

4.2. Test de cobertura con gcov 151 



Pag 5 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 



Tema 1 

Introduccion a las 
herramientas de 
programacion de 

GNU 



Sinopsis: 



En este primer tema vamos a introducir que son las herramientas de 
programacion de GNU, su evolution historica, y como debemos usarlas. 

Esta information es de naturaleza introductoria para el resto del documento, 
con lo que los usuarios mas avanzados, si lo desean, pueden saltarse este 
primer tema y empezar su lectura en el Tema 2. Aunque antes de hacerlo les 
recomendamos echar un vistazo a los conceptos que este tema introduce. 
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1. Las GNU Compiler Collection (GCC) 



En 1984 Richard Stallman inicio el desarrollo de un compilador C al que llamo 
gcc (GNU C compiler). El compilador fue desarrollado con la intencion de 
que los programadores que quisieran participar en el proyecto GNU pudieran 
desarrollar software con vistas a desarrollar un UNIX libre. En aquel entonces 
todos los compiladores que existfan eran propietarios, con lo que se tuvo que 
desarrollar un compilador desde el principio. 

Con el tiempo este compilador evoluciono y paso a soportar varios lenguajes 
(en concreto actualmente soporta C, C++, Objective-C, Java, Fortran y Ada), 
con lo que el nombre (que originariamente indicaba que se trataba de un 
compilador C) tambien evoluciono y paso a escribirse en mayusculas como 
GCC (GNU Compiler Collection). El nuevo nombre pretende indicar que se 
trata, no de un comando, sino de un conjunto de comandos usados para 
poder programar en distintos lenguajes. 

En espanol suele encontrarse el nombre Herramientas de Programacion 

de GNU para referirse a las GCC (la traduccion literal "Coleccion de 
Desarrollo GNU" no parece una traduccion adecuada), y este nombre es el 
que hemos elegido para este tutorial. 

Las GCC son posiblemente el proyecto de software libre mas importante que 
se ha emprendido en el mundo. Principalmente porque todo el software libre 
que se esta empezando a desarrollar se apoya en el. Desde su creacion GNU 
expuso el objetivo claro de ayudar a crear un UNIX libre, y la mejor prueba de 
que este objetivo se ha cumplido es Linux, un sistema operativo creado por 
miles de desarrolladores los cuales siempre han tenido como denominador 
comun las GCC. Ademas las GCC no solo se han usado para crear Linux, sino 
que otros muchos sistemas operativos como las distribuciones BSD, Mac OS X 
o BeOS tambien las han elegido como sus herramientas de desarrollo. 

Actualmente el desarrollo de las GCC esta siendo coordinado por un amplio 
grupo de comunidades procedentes de la industria, la investigacion, y la 
universidad. El grupo que coordina los desarrollos es el GCC steering 
comittee, el cual trata de velar por los principios de software libre bajo los 
que fue creada inicialmente la herramienta. 

Apple eligio las GCC como base de sus herramientas de desarrollo, y aunque 
han creado herramientas de interfaz grafica como Xcode o Interface Builder, 
estas herramientas lo unico que hacen es apoyarse en las GCC para realizar 
su trabajo. Es mas, los empleados de Apple han contribuido a mejorar 
muchos aspectos de las GCC, especialmente en lo que a las optimizaciones 
para PowerPC y AltiVec se refieren. 
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2.Arquitectura del compilador de GNU 



Una caracterfstica de las GCC, que ademas es muy comun de encontrar en el 
software libre, es que el proyecto no ha seguido un proceso formal de 
ingenierfa con fases de analisis, diseno, implementacion y pruebas. GCC esta 
siendo creado por cientos de programadores de distintas nacionalidades 
trabajando sobre un repositorio donde tanto la informacion de analisis como 
la de diseno esta entremezclada con el codigo fuente a base de comentarios. 
Aun asf han conseguido crear una herramienta de calidad, estable, rapida y 
con un bajo consumo de memoria. 



2.1. Frontend y backend 

A groso modo podemos dividir el proceso de compilado en dos partes: 
Frontend y backend. El frontend (donde se realiza el analisis lexico y 
gramatical) lee un fichero de codigo fuente y crea una estructura en forma de 
arbol en memoria de acuerdo a la gramatica del lenguaje. El backend lee 
este arbol y lo convierte en una secuencia de instrucciones ensamblador para 
la maquina destine Dentro del backend podemos incluir tanto el analisis 
semantico, como la generacion de codigo y la optimizacion. 

Aunque los lenguajes que GCC puede compilar son muy distintos, a medida 
que avanzan las fases del frontend se va generando una estructura comun a 
todos los lenguajes, de forma que un mismo backend puede generar codigo 
para distintos lenguajes. Otra caracterfstica de GCC es que usando distintos 
backend podemos generar codigo para distintas plataformas sin necesidad de 
disponer de un frontend para cada plataforma. Esto ha permitido que 
actualmente las GCC sean capaces de generar codigo para casi todos los tipos 
de hardware existentes. 



2.2. Fases del compilador 

Antes de empezar a describir como usar el comando gec, conviene recordar 
al lector las tres fases que tiene la generacion de un ejecutable, por parte un 
compilador: 

1. Preprocesado. Expande las directivas que empiezan por # como 

#define, #include 0 #ifdef. 

2. Compilacion. Traduce el codigo fuente a codigo objeto, un codigo 
cercano al codigo maquina donde las llamadas externas estan sin 
resolver y las direcciones de memoria son relativas. 
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3 . Enlazado. Combina los diferentes ficheros de codigo objeto 
resolviendo las llamadas que han quedado pendientes y asignando 
direcciones definitivas al ejecutable final. 

En el caso de gcc, aunque llamaremos compilacion al proceso global, la etapa 
de compilacion consta de dos partes: 

1 . Compilacion. Donde se traduce el codigo fuente a codigo 
ensamblador. 

2. Ensamblado. Donde se traduce el codigo ensamblador en codigo 
objeto. 

El proceso de compilacion lo realiza en parte el frontend (generando un arbol 
gramatical), y en parte el backend (generando el codigo ensamblador para la 
maquina que corresponda). Tanto el proceso de ensamblado como el de 
enlazado son realizados por el backend. 
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3.Comandos disponibles 



Como ya hemos comentado, actualmente las GCC constan de un gran numero 
de comandos que iremos viendo a lo largo del tutorial, y que hemos resumido 
en la Tabla 1.1. En la tabla tambien indicamos el tema donde se explica su 
funcionamiento. 



Comando 

gcc 


Compilador de las GCC. 


Tema 

1 


ccl 


El romDilador actual dp C a pnsamblador 


2 


as 


Ensamblador que traduce de lenguaje 
pnsamblador a codiao obipto 


2 


Id 


El enlazador de GCC. 


2 


gcc select 


Ppimhipi \r\ x/prQinn HpI rnmnitarlnr niip pQfpmnQ 

Vw-ai i iL/ia la vci oiui i uci Lui i ijjmciuui t|uc cjlci i ivjo 

usando 




c++f ilt 


Elimina los nombres con name mangling de la 
entrada estandar e imDrime el resultado en la 

V— • 1 1 V.I V^iJLLI 1 \— II 1 ll-SI II 1 IV— V— 1 1 vJUIIpUUv V— . 1 1 IU 

salida estandar. 


2 


nm 


Muestra la tabla de sfmbolos de un fichero de 
codigo objeto o de una librerfa. 


2,3 


otool 


Muestra informacion sobre un fichero Mach-O. 


3 


libtool 


Permite generar librerfas tanto de enlace estatico 
como de enlace dinamico. 


3 


cmpdylib 


Compara la compatibilidad entre dos librerfas de 
enlace dinamico. 


3 


strip 


Elimina sfmbolos innecesarios de un fichero de 
codigo objeto. 


3 


g+ + 


Una version de gcc que fija el lenguaje por 
defecto a C++, e incluye las librerfas estandar de 
C++. 


4 


C + + 


Equivalente al anterior. 


4 


collect2 


Genera las inicializaciones de los objetos globales. 


4 


gcj 


Compilador Java de las GCC. 


5 


gij 


Interprete Java de las GCC. 


5 


j cf -dump 


Nos permite obtener informacion sobre el 
contenido de un fichero .class. 


5 


j v-scan 


Recibe un fichero de codigo fuente Java y produce 
distintas informaciones sobre este. 


5 


grep j ar 


Busca una expresion regular en un fichero .jar. 


5 


f ast j ar 


Una implementacion del comando jar de Sun que 
ejecuta considerablemente mas rapido. 


5 


gcjh 


Permite generar los prototipos CNI (o JNI si 
usamos la opcion -jni) de los metodos a 
implementar. 


6 


gdb 


Es el depurador de GNU. Permite ejecutar paso a 


7 
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paso un programa e identificar errores. 




leaks 


Permite identificar fugas de memoria, es decir, 
memoria reservada dinamicamente que nunca se 
libera. 


7 


malloc history 


Permite inspeccionar un log con toda la memoria 
dinamica que ha sido reservada y liberada durante 
la ejecucion de un programa. 


7 


gprof 


Permite perfilar un programa, es decir, detectar 
partes de programa que si se optimizan 
podrfamos conseguir una considerable mejora 
global en su rendimiento. 


7 


gcov 


Permite realizar test de cobertura a un programa, 
es decir, saber cuantas veces se ejecuta cada 
Ifnea del programa. 


7 



Tabla 1.1: Comandos de GCC 



Actualmente no todos los comandos que se describen en este tutorial estan 
disponibles por defecto en Mac OS X (y en general tampoco en ningun otro 
sistema operativo), con lo que si no encuentra alguno de estos comandos en 
su terminal, dejamos como ejercicio para el lector el buscarlo e instalarlo. En 
el caso de Mac OS X, actualmente no esta disponible el compilador de Java de 
GNU, aunque existe una implementacion de la maquina virtual de Sun 
realizada por Apple, es decir, no encontrara comandos como gcj. Le 
recomendamos instalar el paquete mingw-gcc del proyecto Fink, ya que este 
paquete si que incluye muchos de los comandos de las GCC. Si sigue sin 
encontrar algun otro comando de los comentados en este tutorial, 
posiblemente lo encuentre ya portado a Mac OS X dentro del gestor de 
paquetes Fink. 

3.1. Opciones de la Ifnea de comandos 

Las opciones de la Ifnea de comandos siempre empiezan por uno o dos 
guiones. En general, cuando la opcion tiene mas de una letra se ponen dos 
guiones, y cuando solo tiene una letra se pone un guion. Por ejemplo, para 
compilar el fichero hoia.c y generar el fichero de codigo objeto hoia.o, 
usando ANSI C estandar se usa el comando: 

$ gcc hoia.c --ansi -c -o hoia.o 

Vemos que se indican primero los ficheros de entrada (hoia.c en este caso), 
y luego las opciones, algunas de las cuales tienen parametros y otras no. En 
general gcc es bastante flexible y suele aceptar que le pasemos las opciones 
en cualquier orden. 
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Las opciones de una sola letra, si reciben parametros estos pueden ir 
separados por espacio o ir juntos, es decir, en el ejemplo anterior podrfamos 
haber usado -ohoia . o en vez de -o hoia . o. 

Las opciones de la Ifnea de comandos se pueden clasificar entres categorfas: 

1. Especfficas del lenguaje. Son opciones que solo se pueden usar junto 
con determinados lenguajes de programacion. Por ejemplo, -C8 9 solo 
se usa en C para indicar que queremos usar el estandar ISO de 1989. 

2. Especfficas de la plataforma. Son opciones que solo se usan en 
determinada plataforma. Por ejemplo -f-ret-in-387 se usa solo en 
Intel para indicar que el retorno en punto flotante de las funciones se 
haga en un registro de punto flotante. 

3. Generales. Son opciones que se pueden usar en todos los lenguajes y 
en todas las plataformas, como por ejemplo -o usada para indicar que 
queremos optimizar el codigo objeto resultante. 

Como veremos mas adelante, hay opciones que no van dirigidas al 
compilador sino al enlazador. Cuando gcc recibe una opcion que no entiende 
simplemente la pasa al enlazador esperando que este la sepa interpretar. 

3.2. Variables de entorno 



Ademas de usando opciones, el comportamiento de gcc puede ser 
personalizado usando variables de entorno. Las principales variables de 
entorno que afectan el comportamiento de gcc se resumen en la Tabla 1.2. 



Var. de entorno 


Descripcion 


LIBRARY PATH 


Lista de directories, separados por dos puntos, en 
la que se indica en que directories buscar librerfas. 
Si se indica la opcion -l primero se busca en la 
ruta dada por la opcion, y luego en la dada por la 
variable de entorno. 


CPATH 


Directorio donde buscar ficheros de cabecera tanto 
para C, C++ y Objective-C. 


C INCLUDE PATH 


Directorio donde buscar ficheros de cabecera. 
Variable de entorno usada solo por C. 


CPLUS INCLUDE PATH 


Directorio donde buscar ficheros de cabecera. 
Variable de entorno usada solo por C++. 


OBJC INCLUDE PATH 


Directorio donde buscar ficheros de cabecera. 
Variable de entorno usada solo por Objective-C. 



Tabla 1.2: Principales variables de entorno de gcc 
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Con las variables cpath, c_include_path, cplus_include_path y 
objc include path, si se indica como un elemento de la lista el directorio 
vacfo, se busca en el directorio actual. Por ejemplo si cpath vale /sw/iib: :, 
es equivalente a usar -i. -i/sw/iib. Ademas el primer elemento no debe 
ser dos puntos o se interpreta como un elemento vacfo. Por ejemplo en el 
ejemplo anterior serfa equivalente que cpath valiese : /sw/iib. 



3.3. Empezar a manejar gcc 

Si nosotros pasamos a gcc un programa como el del Listado 1.1, ejecutando: 

$ gcc hola.c 

Este lo compilara y enlazara generando como salida el fichero ejecutable 

a . out: 

$ a . out 

Hola mundo 

/* hola.c */ 

#include <stdio.h> 

main ( ) 
{ 

printf("Hola mundo\n"); 
return 0; 



Listado 1.1: Programa C mfnimo 



Si preferimos que el fichero de salida tenga otro nombre podemos indicarlo 
con la opcion -o. Por ejemplo, el siguiente comando genera el fichero 
ejecutable hoia. 

$ gcc hola.c -o hola 
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Tema 2 

Compilando en C 



Sinopsis: 



En este segundo tema pretendemos detallar el funcionamiento del compilador 
en lo que al lenguaje C se refiere. 

Empezaremos viendo el funcionamiento del preprocesador, para luego 
detallar las opciones de Imea de comandos propias del lenguaje C. Por ultimo 
veremos que extensiones al C estandar introducen las GCC. 
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l.EI preprocesador 



El concepto de preprocesador fue introducido inicialmente por C, pero 
despues otros lenguajes como C++ o Objective-C lo han heredado. 

El programa encargado de realizar el preproceso es un comando llamado 

cpp 1 . 

1.1. Opciones relacionadas con el preprocesador 



Existen una serie de opciones relacionadas con el preprocesador que se 
resumen en la Tabla 2.1. 



Opcion 




-D 


Define un identificador del preprocesador (que puede ser un 
macro). Para ello usamos -d nombre= [valor] , donde si no 
asignamos valor, por defecto nombre vale 1. 


-u 


Usar la opcion -u nombre cancela el identificador del 
preprocesador previamente definido. El identificador podrfa haber 
sido definido en un fichero, o con la opcion -d. 


-I 


-i directorio incluye directorio en la lista de directories 
donde buscar ficheros de cabecera. El directorio aquf pasado se usa 
antes que los directorios de inclusion estandar, con lo que esta 
opcion nos permite sobrescribir ficheros de cabecera estandar. 


-W 


Existen algunos warnings relacionados con el preprocesador como 
por ejemplo -wunused-macros que indica que queremos generar 
un warning si un identificador del preprocesador definido en un . c 
no es usado en todo el fichero. Esta opcion no afecta a los 
identificadores definidos, y no usados, en los ficheros de cabecera, 
o en las opciones del preprocesador. 



Tabla 2.1: Principales opciones relacionadas con el preprocesador 



Como ya comentamos en el apartado 3.2 del Tema 1, las variables de entorno 

C PATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH y OB JC_INCLUDE_PATH 

tambien permiten indicar directorios donde buscar ficheros de cabecera. 



1 Razon por la que al compilador de C++ se le llamo c++ (o g++) y no cpp. 
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1 .2. Identificadores del preprocesador desde la Ifnea 
de comandos 

Los identificadores del preprocesador siempre se pueden crear con la 
sentencia del preprocesador # define, pero ademas existe una serie de 
identificadores predefinidos que podemos obtener ejecutando el comando 
cpp con la opcion -dM sobre un fichero vacfo. 

$ cpp -dM /dev/null 

#define APPLE 1 

#define DECIMAL_DIG 17 

#define DYNAMIC 1 

#define GNUC 3 

Por otro lado siempre podemos definir identificadores desde la Ifnea de 
comandos usando la opcion -d, lo cual es util muchas veces para controlar la 
forma en que compila nuestro programa. Por ejemplo, el programa del 
Listado 2.1 usa el identificador depurable para decidir si imprimir 
informacion de depuracion. Para definir el identificador del preprocesador 
desde la Ifnea de comandos podemos hacer: 

$ gcc -DDE PURANDO depurable . c 



/* depurable. c */ 

#include <stdio.h> 
#include <math.h> 

int main ( ) 
{ 

double w=exp (M_PI/2 ) ; 
#ifdef DE PURANDO 

printf("w vale %f",w); 
#endif 
return 0; 



Listado 2.1: Programa que usa un identificador del preprocesador 

Si no indicamos valor para el identificador, por defecto vale 1, podemos 
indicar un valor para el identificador de la forma: 

$ gcc -DDEPURANDO=si depurable . c 

En caso de que el valor tenga espacios u otros sfmbolos especiales debemos 
de entrecomillar el valor de la forma -ddepurando=" imprime mensaje". 
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1 .3. Rutas de los f icheros de cabecera 

Las sentencias del preprocesador de la forma: 

#include <fichero.h> 

Buscan ficheros de cabecera en los directorios de inclusion estandar, que 

en la mayorfa de los SO (incluido Mac OS X) son, por este orden: 

/usr/ local/ include 
/ usr/ include 

Si usamos la sentencia del preprocesador con comillas: 



Ademas tambien se buscan los ficheros de cabecera en el directorio actual. 

Si queremos que se busquen ficheros de cabecera en otros directorios 
debemos usar la opcion -i, la cual debe de usarse una vez por cada nuevo 
directorio a anadir a la lista de directorios de ficheros de cabecera. Por 
ejemplo, para que busque ficheros de cabecera en /sw/ include y 

/usr/xii/inciude debemos de usar: 



$ gcc -I/sw/include -I/usr/Xll/include fichero.cpp 
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2.Usando el compilador de C 



La Tabla 2.2 presenta las extensiones de fichero utilizadas por las GCC en el 
caso del lenguaje C. 



Extension 


Description 


. a 


Librerfa de enlace estatico. 


. c 


Codigo fuente C que debe ser preprocesado. 


.h 


Fichero de cabecera. 


. i 


Codigo fuente C que no debe ser preprocesado. Este tipo de 
fichero se puede producir usando el preprocesador. 


. o 


Fichero objeto en formato adecuado para ser usado por el 
enlazador id. 


. s 


Codigo ensamblador. Este fichero puede ser ensamblado con el 
comando as. 


. so 


Librerfa de enlace dinamico. 



Tabla 2.2: Extensiones usadas por las GCC para el lenguaje C 



2.1 . Compilar y enlazar codigo fuente C 

Para realizar la compilacion en sentido global (compilacion y ensamblado) de 
un fichero (pero no su enlazado) se usa la opcion -c. Por ejemplo, para 
realizar la compilacion del programa del Listado 1.1, que repetimos por 
comodidad en el Listado 2.2, podemos ejecutar: 

$ gcc hola.c -c 



Esto genera el fichero objeto hoia.o, donde si queremos cambiar el nombre 
por defecto del fichero de salida tambien podnamos usar la opcion -o. 



/* hola.c */ 




#include <stdio.h> 




int main ( ) 




{ 




printf("Hola mundo\n"); 




return 0; 





Listado 2.2: Programa C en un solo fichero 



Una vez que tenemos el codigo objeto podemos generar el fichero ejecutable 
usando: 
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$ gcc hola.o -o hola 

Si lo que tenemos son varios ficheros, como por ejemplo los del Listado 2.3 y 
Listado 2.4, podemos compilar ambos ficheros con el comando: 

$ gcc holamain.c saluda.c -c 

Lo cual genera los ficheros de codigo objeto hoiamain.o y saiuda.o. 



/* holamain.c */ 

void Saluda ( ) ; 

int main ( ) 
{ 

Saluda ( ) ; 
return 0; 

} 

Listado 2.3: Programa principal con llamadas a otro modulo 



/* saluda.c */ 

#include <stdio.h> 

void Saluda ( ) 
{ 

printf("Hola mundo\n"); 
_} 

Listado 2.4: Modulo con una funcion C 

Ahora podemos enlazar los ficheros de codigo objeto con: 

$ gcc hoiamain.o saiuda.o -o hola2 

Y logicamente tambien podemos realizar ambas operaciones a la vez con el 
comando: 

$ gcc holamain.c saluda.c -o hola2 



2.2. Preprocesar y generar codigo ensamblador 

Como hemos dicho en el apartado 2.2 del Tema 1, la compilacion consta de 
dos partes, una de compilacion en si donde se genera un fichero en lenguaje 
ensamblador, y otra de ensamblado donde a partir de un fichero en lenguaje 
ensamblador se genera otro de codigo objeto. 
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Podemos pedir que se realice solo la fase de compilacion, generando un 
fichero ensamblador a partir del programa C del Listado 2.2, usando la opcion 
-s de la siguiente forma: 

$ gcc hola.c -S 

Esto genera el fichero hoia.s con el programa C traducido a ensamblador. 
Logicamente ahora podemos ensamblar este fichero generando uno de 
codigo objeto con el comando: 

$ gcc hoia.s -c 

0 generar directamente el ejecutable con: 

$ gcc hoia.s -o hola 

Tambien podemos indicar a gcc que queremos realizar solo la etapa de 
preprocesado con la opcion -e: 

$ gcc hola.c -E -o hola.i 

Este comando preprocesa las directivas del fichero hola.c, y genera el 
fichero hoia.i con el codigo C preprocesado. Como se indica en la Tabla 2.2, 
la extension . i la usa gcc para referirse a los ficheros preprocesados, con lo 
que si ahora ejecutamos: 

$ gcc hola.i -c 

Lo compila, pero ya no volverfa a ejecutar el preprocesador sobre el fichero. 

2.3. El comando gcc es un driver 

Para ejecutar la fase de enlazado lo que hace gcc es ejecutar el comando id. 
Este programa tambien lo podemos ejecutar nosotros de forma individual si 
tenemos un fichero de codigo objeto. Por ejemplo en el caso anterior 
podemos hacer: 

$ Id hola.o -lcrtl.o -lSystem -o hola 

La opcion -l sirve para indicar librerfas contra las que queremos enlazar. Con 
la opcion -ictri.o indicamos a id que queremos enlazar el runtime de 
arranque de C para consola, es decir, el codigo que se ejecuta antes de 
empezar a ejecutar la funcion maino. Con la opcion -lsystem indicamos 
que queremos enlazar funciones basicas del lenguaje C, como por ejemplo 

printf ( ) . 
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De hecho gcc es lo que se llama un driver, porque es un comando que se 
encarga de ejecutar otros comandos. En concreto primero gcc ejecuta el 
comando cci que es el compilador actual de C, es decir, el que traduce de C 
a ensamblador 1 , luego ejecuta el comando as que es el ensamblador actual, y 
por ultimo ejecuta el comando id que enlaza el programa con las librerfas C 
necesarias. 

Podemos preguntar a gcc que comandos esta ejecutando al actuar como 
driver con la opcion -###. Por ejemplo: 

$ gcc hola.c -### 

Reading specs from /usr/libexec/gcc/darwin/ppc/3 . 3/specs 
Thread model: posix 

gcc version 3.3 20030304 (Apple Inc. build 1809) 

"/usr/libexec/gcc/darwin/ppc/3 . 3/ccl" "-quiet" "-D GNUC 

=3" "-D GNUC_MINOR =3" "-D GNUC_PATCHLEVEL =0" "-D_ 

_APPLE_CC =1809" "-D DYNAMIC " "hola.c" "-fPIC" "-quie 

t" "-dumpbase" "hola.c" "-auxbase" "hola" "-o" "/var/tmp/ 
/ ccQnqpw8 . s " 

" /usr/libexec/gcc/darwin/ppc/as" "-arch" "ppc" "-o" "/va 
r/ tmp/ /ccEntkj 5 . o" " /var/ tmp/ / ccQnqpw8 . s " 

"Id" "-arch" "ppc" "-dynamic" "-o" "a. out" "-lcrtl.o" "- 
lcrt2.o" "-L/usr/lib/gcc/darwin/3 . 3 " "-L/usr/lib/gcc/darw 
in" "-L/usr/libexec/gcc/darwin/ppc/3 . 3/ ../../.. " "/var/tm 
p//ccEntkj5 .o" "-lgcc" "-lSystem" | 

"c++filt" 

En negrita hemos marcado los comandos que ejecuta el driver. El 
entrecomillado de los argumentos de los comandos es opcional si estos no 
tienen espacios, aun asf el driver los entrecomilla todos. 

El ultimo comando c++fiit, al que id pasa su salida, elimina el name 
mangling de los sfmbolos del texto que recibe como entrada y imprime el 
texto recibido en la salida. Esto se hace para facilitar su legibilidad por parte 
del usuario, si el enlazador informa de nombres de sfmbolos sin resolver. 

Si las opciones de compilacion que recibe gcc que no son validas para el 
compilador gcc se las pasa al siguiente elemento de la cadena que es el 
ensamblador, y si este tampoco las puede interpretar se pasan al enlazador. 
Por ejemplo las opciones -1 y -l son opciones del enlazador, y cuando las 
recibe gcc, este sabe que son propias del enlazador con lo que no se las pasa 
al compilador. 

Hay algunas opciones, como por ejemplo -x, que son validas tanto para el 
compilador como para el enlazador. En el caso del compilador sirve para 
indicar el lenguaje en que estan hechos los ficheros de entrada, y en el caso 
del enlazador sirve para indicar que elimine los sfmbolos no globales que no 



1 El comando cci a su vez llama al comando cpp para que realice el preprocesado. 
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se esten usando. Por defecto gcc enviarfa la opcion al compilador, con lo que 
si queremos que se la envfe al enlazador debemos de precederla por la opcion 
-xi inker. Por ejemplo, para indicar que el programa esta hecho en C++ 
(aunque tenga extension . c), y pedir al enlazador que elimine los sfmbolos no 
globales que no se esten usando, podemos hacer: 

$ gcc hola.c -x cpp -Xlinker -x 

2.4. Estandares 

Por defecto gcc compila un programa C con todas las sintaxis extendidas del 
lenguaje habilitadas. Si queremos utilizar solo determinado estandar, la Tabla 
2.3 muestra un resumen de las opciones que permiten indicar el estandar a 
seguir. 



Opcion 


Description 


-traditional 


Compila con la sintaxis del C original. 


-std=c89 


Acepta el estandar ISO C89. 


-ansi 


Igual que -iso=c89. 


-std=c99 


Acepta el estandar ISO C99. 


-std=gnu8 9 


Acepta el estandar ISO C89 mas las extensiones de GNU. 
Es la opcion por defecto si no se indica. 


-std=gnu99 


Acepta el estandar ISO C99 mas las extensiones de GNU. 


-pedantic 


Emite todos los warnings que exigen los estandares ISO, y 
obliga al cumplimiento del estandar. 



Tabla 2.3: Opciones para indicar el estandar C a seguir 



El uso de opciones como -ansi o -std=c99 no hace que se rechacen las 
extensiones de GNU. Si queremos garantizar que nuestro programa cumple 
estrictamente los estandares ISO (y en consecuencia compila con otros 
compiladores) debemos de anadir la opcion -pedantic, en cuyo caso 
tampoco produce un error el usar las extensiones de GNU, pero si que 
produce warnings avisando de la circunstancia. Si, por contra, queremos que 
una violacion del estandar ISO produzca un error, en vez de un warning, 

podemOS USar la Opcion -pedantic-error. 

2.5. Indicar el lenguaje a utilizar 

El driver gcc utiliza la extension de los ficheros para determinar el lenguaje 
utilizado. Por ejemplo si el fichero tiene la extension . c utiliza el programa 
cci para compilarlo. En ocasiones podemos tener el codigo fuente en un 
fichero con distinta extension. En este caso podemos usar la opcion -x para 
indicar el lenguaje en que esta hecho el programa. Por ejemplo: 
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$ gcc -x C++ hola.c 

Compila el programa hoia.c con el compilador de C++, en vez de con el del 
lenguaje C. 

3.Extensiones al lenguaje C 



Como ya comentamos en el Acerca de, en este tutorial estamos suponiendo 
que el lector conoce el lenguaje C, y no vamos a explicar como se usa el 
lenguaje. Lo que vamos a ver en este apartado es que extensiones al 
lenguaje C han introducido las GCC. Muchas extensiones al lenguaje que ha 
introducido inicialmente las GCC han sido adoptadas luego por el estandar 
ISO, aunque en este apartado vamos a exponer solo las extensiones que a 
dfa de hoy no forman parte del estandar. 

Sin no desea usar estas extensiones de las GCC siempre puede usar la opcion 
-ansi, -std=c89 o -std=c99 para evitar el funcionamiento por defecto que, 
como se indica en la Tabla 2.3 es -std=gnu8 9. Si ademas usa la opcion - 
pedantic obtendra un warning cada vez que use una extension (a no ser que 
preceda la extension con la palabra clave extension ). 

Debido a que C es la base de otros lenguajes como C++ o Objective-C, 
muchas de las extensiones que aquf se explican son validas tambien en estos 
otros lenguajes. 

3.1. Arrays de longitud variable 

En C estandar la longitud de un array debe conocerse en tiempo de 
compilacion, con esta extension vamos a poder dar la longitud de un array de 
forma que sea calculada en tiempo de ejecucion. El Listado 2.5 muestra un 
ejemplo de como se hace esto. Observe que la longitud del array combi no se 
conoce hasta el tiempo de ejecucion. 



void Combina (const char* strl, const char* str2) 
{ 

char combi [strlen (strl) +strlen (str2) +1] ; 
strcpy (combi, strl) ; 
strcat (combi, str2) ; 
printf (combi) ; 

Listado 2.5: Ejemplo de uso de arrays de longitud variable 

Tambien podemos pasar como parametros de una funcion arrays de longitud 
variable, tal como muestra el ejemplo del Listado 2.6. 
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void RellenaArray (int longitud, char letras [ longitud] ) 
{ 

int i; 

for ( i=0 ; i<longitud; i++) 



letras [i] = 'A'; 




Listado 2.6: Array de longitud variable pasado como parametro 



Podemos invertir el orden de los parametros haciendo una declaracion 
adelantada de la longitud: 

void RellenaArray ( int longitud; char letras [ longitud] 



En este caso las declaraciones adelantadas se ponen delante de los 
parametros. Puede haber tantas declaraciones adelantadas como queramos, 
separadas por coma o punto y coma, y acabadas en punto y coma. 



3.2. Arrays de longitud cero 

Las GCC permiten crear dentro de estructuras arrays de longitud cero. De 
esta forma podemos crear zonas de memoria de longitud variable a las que 
accedemos con el array. Aunque no es necesario, estos arrays suelen ser el 
ultimo campo de la estructura. El programa del Listado 2.7 ilustra el uso de 
esta tecnica. En el ejemplo sizeof (cadenavariabie) devuelve 4 porque el 
array mide 0 bytes para sizeof o, pero si luego indireccionamos con pc- 
>ietras [i] podemos acceder a los bytes siguientes a la memoria ocupada 
por la estructura. 



/* arraycero.c */ 

#include <stdio.h> 
#include <string.h> 

typedef struct 
{ 

int tamano; 
char letras [ 0 ] ; 
} CadenaVariable; 

main ( ) 
{ 

int i; 

char* cadena = "Hola que tal"; 
int longitud = strlen ( cadena) ; 
CadenaVariable* pc = (CadenaVariable*) 

malloc (sizeof (CadenaVariable) +longitud) ; 
pc->tamano = longitud; 
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strcpy (pc->letras , cadena) ; 
for (i=0; i<pc->tamano; i++) 

printf("%c ",pc->letras [i] ) ; 
printf ("\n") ; 
return 0; 

} 

Listado 2.7: Ejemplo de array de longitud cero 

El mismo objetivo se puede conseguir definiendo el array sin indicar longitud. 
Esto no solo tiene la ventana de ser C estandar, sino que ademas nos permite 
indicar los elementos del array en la inicializacion. El Listado 2.8 muestra 
como usar array de longitud indefinida. 



* arrayindef inido */ 

#include <stdio.h> 
#include <string.h> 

typedef struct 
{ 

int tamano; 
char letras [ ] ; 
} CadenaVariable; 

CadenaVariable c = { 12 , { ' H ' , ' o ' , ' 1 ' , ' a ' , ' ' , ' q ' , ' u ' , ' e ' 

, ' ', 't', 'a', '1', '\0' }; 

main ( ) 
{ 

printf ("%s ocupa %i bytes para sizeof()\n" 

,c. letras, sizeof (c) ) ; 
return 0; 

} 

Listado 2.8: Ejemplo de array de longitud indefinida 



3.3. Rangos en la sentencia case 

En C estandar podremos definir varios casos en una sentencia switch de la 
forma: 

case 8: 
case 9: 
case 10: 

En C de GNU podemos usar la forma alternativa: 
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Es importante encerar la elipsis (...) entre espacios, para evitar que el 
parser confunda el rango con un numero en punto flotante. El uso de rango 
en sentencias case es muy tfpico encontrarlo en el caso de rangos de 
caracteres constantes de la forma: 



3.4. Declarar variables en cualquier punto del 
programa 

Si en vez de usar el lenguaje C por defecto (que recuerde que es - 
std=gnu89) usa -std=c99 o -std=gnu99 (es decir, si usa es el estandar ISO 
C99) podra declarar variables en cualquier punto del programa (incluido 
dentro de un bucle for), y no solo al principio de un ambito. Esta forma de 
declarar es valida siempre en C++, pero en C solo lo es cuando use ISO C99. 
El Listado 2.9 muestra un ejemplo de declaracion de variables. 



/* declaraciones . c 


*/ 


#include <stdio.h> 




int main ( ) 




{ 

printf ("Empezamos 


:\n") ; 


char letra = 'A' ; 




for (int i=0;i<10; 


i++) 


printf ("%c", le 


tra) ; 


printf ("\n") ; 




return 0; 

} 





Listado 2.9: Ejemplo de declaracion de variables en cualquier punto del programa 



Recuerde que para compilar el Listado 2.9 debera usar el comando: 

$ gcc -std=c99 declaraciones . c 



3.5. Numeros largos 

El estandar ISO C99 ha definido la forma de crear enteros de dos palabras, es 
decir, enteros de 64 bits en maquinas de 32 bits, y enteros de 128 bits en 
maquinas de 64 bits. Para ello anadimos long long al tipo, por ejemplo, en 
una maquina de 32 bits podemos declarar: 

long long int i; // Entero con signo de 64 bits 

unsigned long long int ui; // Entero sin signo de 64 bits 
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Las constantes para estos tipos lo que hacen es llevar el sufijo ll. Por 
ejemplo: 

i = -7423242050344LL; 

ui = 48452525434534943LL; 



3.6. Atributos 

La palabra clave attribute se puede poner al final de la declaration de 

una funcion, una variable, o un tipo de dato con el fin de personalizar el 
comportamiento del compilador. 

En el caso de las funciones, como vemos en el Listado 2.10, el atributo se 
pone al final del prototipo (no de la implementation). El Listado 2.10 tambien 
muestra como se ponen atributos a las variables de tipos de datos. Como 
vemos, los atributos tambien se pueden poner a los campos de una 
estructura. 



struct PaqueteDatos 
{ 

char tipo; 

int padre attribute ( (aligned (4) )) ; 

}; 

int TipoError attribute ((deprecated)) = 0; 

void ErrorFatal (void) attribute ( (noreturn) ) ; 

void ErrorFatal (void) 
{ 

printf ( "Houston, tenemos un problema" ) ; 
exit ( 1 ) ; 

} 

int getLimite() attribute ( (pure, noinline) ) ; 

Listado 2.10: Ejemplo de uso de atributos 

Una declaration puede tener varios atributos, en cuyo caso se ponen 
separados por coma, como en el caso de la funcion getLimite o del Listado 
2.10. 



La Tabla 2.4 muestra los atributos aplicables a las funciones, la Tabla 2.5 los 
atributos aplicables a la declaration de variables y la Tabla 2.6 los atributos 
aplicables a las declaraciones de tipos de datos. 



Atributo 




deprecated 


Hace que siempre que el compilador detecte una 
llamada a una funcion marcada con este atributo 
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produzca un mensaje donde se le indique que la funcion 
esta obsoleta. 


section 


Permite indicar una seccion alternativa para la funcion. 

Por ejemplo void foobar(void) attribute 

( (section ("bar") ) ) ; indica que la funcion foobar () 

debe colocarse en la seccion bar. 


constructor 


Una funcion marcada con este atributo es ejecutada 
automaticamente antes de entrar en la funcion main o . 
Este atributo es usado por los constructores de objetos 
C++ globales. Vease el apartado 5 del Tema 4. 


desctructor 


Una funcion marcada con este atributo es ejecutada 
despues de salir de la funcion main ( ) , o despues de 
ejecutar exit o .Vease el apartado 5 del Tema 4. 


nonnull 


Permite indicar parametros de la funcion de tipo puntero 
que no pueden ser null en la llamada. Vease mas 
adelante la explicacion. 


format 


Permite que el compilador compruebe los atributos que 
recibe una funcion que tiene una cadena de formato. Ver 
explicacion mas abajo. 


weak import 


Permite declarar referencias weak. Su uso lo veremos en 
el apartado 2.8.3 del Tema 3. 


cdecl 


Estilo de llamada a funciones por defecto de C. Atributo 
valido solo en maquinas Intel. 


stdcall 


Estilo de llamada a funciones al estilo Pascal. Atributo 
valido solo en maquinas Intel. 


f astcall 


Una forma de llamar a funciones mas rapida que la 
anterior. En concreto los dos primeros parametros, en 
vez de pasarse por la pila, se pasan en los registros ecx 
y edx. Atributo valido solo en maquinas Intel. 


always inline 


Una funcion que ha sido declarada con el modificador 
inline no suele expandirse inline a no ser que este tipo 
de optimizacion este activada. Con este atributo la 
funcion siempre se expande inline, incluso aunque este 
activada la depuracion. Vease el apartado 2.1 del Tema 
7. 


noinline 


Impide que una funcion se implemente inline, aunque 
este activado este tipo de optimizacion. Vease el 
apartado 2.1 del Tema 7. 


pure 


Indica al compilador que esta funcion no tiene efectos 
laterales, es decir, que no modifica variables globales, 
zonas cuya direccion de memoria recibe como 
parametro, ni ficheros. A diferencia de con el atributo 
const, esta funcion si que puede leer estos valores. Este 
atributo le sirve al optimizador para optimizar 
subexpresiones. Esta opcion permite que la funcion sea 
llamada menos veces de lo que dice el programa. Por 
ejemplo para calcular una rafz cubica en una expresion 
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puede no ser necesario llamar varias veces a la funcion 
si el parametro de la funcion no cambia. 


const 


Este atributo es parecido a pure, pero ademas de indicar 
que no modifica, indica que tampoco lee los valores 
indicados. 


noreturn 


Indica que la funcion no retorna. Esto permite que el 
compilador optimice el codigo de la funcion al no poner 
preambulo de retorno. El Listado 2.10 muestra un 
ejemplo de uso de este atributo en una funcion que 
termina el programa llamando a exit o . 


visibility 


Permite indicar la visibilidad de una funcion a la hora de 
exportarla en una librerfa de enlace dinamico. Vease el 
apartado 2.6.2 del Tema 3. 



Tabla 2.4: Atributos aplicables a las funciones 



El atributo nonnuii permite indicar que un parametro de una funcion no 
deberfa de ser null. Si pasamos null en este atributo el compilador lo 
detecta y emite un warning. Para que el compilador emita el warning es 
necesario haber pasado la opcion -wnonnuii, o bien -wall (que es la que se 
usa para avisar de todo tipo de warnings). En el atributo podemos indicar los 
parametros sometidos a este control como muestra el siguiente ejemplo. 

void* mi_memcpy (void *dest, const void *src, size_t len) 

attribute ((nonnull (1, 2))); 

Si no se indican numeros de parametros, todos los parametros punteros 
deben de no ser null. Por ejemplo, en este otro prototipo todos los 
parametros punteros deben de no ser null: 

void* mi_memcpy (void *dest, const void *src, size_t len) 

attribute ( (nonnull) ) ; 



El atributo format permite construir funciones tipo printf o, es decir, 
funciones que reciben como parametro una cadena con el formato, y despues 
un numero variable de parametros. Esto permite que el compilador 
compruebe que los tipos de la lista variable de parametros coincidan con la 
cadena de formato. Por ejemplo, la siguiente funcion recibe como segundo 
parametro una cadena de formato tipo printf, y el compilador comprueba 
que los parametros a partir del tercero sigan este formato. 

void Mensa j eLog (void* log, char* formato,...) 

attribute ( (format (printf, 2,3))); 

Existen distintos tipos de formatos: En concreto los formatos que acepta este 

atributo SOn printf, scanf, strftime y strfmon. 
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Atributo 


Description 


deprecated 


Una variable con este atributo hace que el compilador 
emita un warning, siempre que el programa intente 
usarla, indicando que la variable esta obsoleta. 


aligned 


Indica que la variable debe de estar en una posicion de 
memoria multiplo del valor indicado. 


section 


Nos permite indicar que una variable debe crearse en su 
propio segmento y seccion en vez del segmento 
estandar data y las secciones estandar data y bbs. Por 
ejemplo para crear una variable en el segmento data y 
en la seccion eventos podemos hacer: 

int raton attribute 

( (section ("DATA, eventos") ) ) = 0; 


visibility 


Permite indicar la visibilidad de una variable a la hora de 
exportarla en una librerfa de enlace dinamico. Vease el 
apartado 2.6.2 del Tema 3. 


Tabla 2.5: Atributos aplicables a la declaracion de variables 


Atributo 


Description 


deprecated 


Este atributo puesto en un tipo de dato hace que el 
compilador emita un warning, indicando que la variable 
esta obsoleta, siempre que intente instanciar una 
variable de este tipo. 


aligned 


Una variable de un tipo con este modificador es una 
variable que el compilador debe colocar en memoria en 
una posicion multiplo del numero pasado como 
argumento. Vease el Listado 2.10 para ver un ejemplo 
de su uso. 



Tabla 2.6: Atributos aplicables a las declaraciones de tipos de datos 



3.7. Valor de retorno de sentencias compuestas 

Un sentencia compuesta es un bloque de sentencias encerradas entre Haves. 
Cada sentencia compuesta tiene su propio ambito y puede declarar sus 
propias variables locales, por ejemplo: 

{ 

int a = 5; 
int b; 
b = a+5; 

} 

En el C de GNU, si encerramos una sentencia compuesta entre parentesis 
podemos obtener como valor de retorno el valor de retorno de la ultima 
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sentencia, y el tipo del retorno sera el mismo que el de la ultima sentencia del 
bloque, por ejemplo, el valor de retorno de la siguiente sentencia sera 8: 

ret = ({ 

int a = 5; 
int b; 
b = a+5; 
} ) ; 



Esta construccion es util para escribir macros. Un conocido problema con los 
macros se produce cuando un parametro del macro se usa en mas de un 
lugar de su implementacion, por ejemplo, en el siguiente macro: 

#define siguiente_par (x) ( (x%2==0) ? x : x+1 ) 

El macro funciona bien, hasta que lo ejecutemos de la forma: 

int par = siguiente_par (n++) ; 

Donde se produce el efecto lateras de que n se incrementa 2 veces. Una 
forma de solucionar este efecto lateral serfa la siguiente: 

#define siguiente_par (x) \ 
({ \ 

int aux = x; \ 

( (aux%2==0) ? aux : aux+1) ; \ 
}) 



3.8. Operador condicional con operandos omitidos 

En el operador condicional se evalua la condicion, y dependiendo de si esta se 
cumple o no se devuelve uno de los operandos que aparecen detras. Al usar 
este operador es muy tfpico usar construcciones donde se compruebe si una 
variable es cero, por ejemplo: 



Comprueba si y es distinta de cero, en cuyo caso se asigna a y a x, y sino se 
asigna a x el valor de z. 

Para evitar problemas debidos a evaluar dos veces y, como el descrito en el 
apartado anterior, el C de GNU tambien permite omitir el operando y escribir 
la expresion anterior de la forma: 
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3.9. Nombre de funcion como cadena 

Ademas de los identificadores del preprocesador especiales file y 

line , el C de GNU tiene la palabra reservada function que nos 

devuelve el nombre de la funcion en la que nos encontramos. 

Esto es util para hacer cosas como: 

char* msg = "Es la funcion " FUNCTION " del fichero " 

FILE ; 

Actualmente la palabra reservada function esta obsoleta en favor de la 

palabra reservada f unc propuesta por el estandar ISO C99. 



3. 10. Macros con numero variable de argumentos 



Existen dos formas de definir macros con numero variable de argumentos. 
Esto se debe a que primero GCC hizo una extension, y luego el estandar ISO 
C99 propuso otra distinta. 

La forma propuesta por el estandar ISO C99 es: 

Donde la lista de parametros del macro que vayan en la elipsis (...) se 
sustituyen en va args . 

La sintaxis de la extension de GNU es esta otra: 

tdefine msg_error ( fmt, args . . . ) fprintf (stderr, fmt, args) ; 



3.11. El operador typeof 

El C de GNU anade el operador typeof, el cual nos devuelve el tipo de una 
expresion. Su uso es parecido al del operador sizeof, pero en vez de 
devolver una longitud devuelve un tipo. A continuacion se muestran algunos 
ejemplos de su uso: 

char* str; 

typeof (str) str2; / / Un char* 

typeof (*str) ch; / / Un char 

typeof (str) Al[10]; // Eguivale a char* Al[10] 

El operador typeof tambien puede recibir nombres de tipos: 
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typeof (char*) str; 



Se estara preguntando para que sirve este operador. Su principal aplicacion 
son los macros, por ejemplo el siguiente macro evita el efecto lateral que 
explicamos en el apartado 3.7: 

#define max (a,b) \ 

( { typeof (a) _a = (a) ; \ 
typeof (b) _b = (b) ; \ 

_a > _b ? _a : _b; }) 

El operador typeof tambien facilita la creacion de macros que sirven para 
definir tipos. Por ejemplo: 

#define vector (tipo, tamano) typeof (tipo [tamano] ) 



Tengase en cuenta que la declaration de variable anterior despues de pasar 
por el preprocesador se convierte en: 



Esta forma de declarar un array si que es valida, a pesar de que: 



No sea una forma valida de declarar el array. 

El estandar ISO ha introducido tambien este operador con el nombre 
typeof , con lo que actualmente ambas formas son validas en las GCC. 



3.12.Uniones anonimas en estructuras 

Esta es una opcion definida por el estandar para C++, pero no para C, 
aunque las GCC la hacen disponible desde el lenguaje C. 

Las uniones anonimas en estructuras nos permiten definir dos campos 
dentro de una estructura que ocupan posiciones solapadas de memoria, sin 
necesidad de dar un nombre a la union. El Listado 2.11 muestra la forma de 
definir campos solapados dentro de una estructura de acuerdo al C estandar. 
Las GCC ademas permiten usar uniones anonimas dentro de estructuras como 
muestra el Listado 2.12. En el C estandar para acceder al campo descriptor 
de la union debemos usar registro . datos . descriptor, con la union 

anonima USamOS la forma registro. descriptor. 
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struct 




{ 




int codigo; 




union 




{ 

int descriptor; 




char campos [ 4 ] ; 




} datos; 




} registro; 







Listado 2.11: Ejemplo de union dentro de estructura de acuerdo al C estandar 



struct 
{ 

int codigo; 
union 

{ 

int descriptor; 
char campos [ 4 ] ; 
}; 

1 registro; 

Listado 2.12: Ejemplo de union anonima dentro de estructura 



3. 13. Casting a un tipo union 

Otra extension del C de GNU permite que un tipo de dato que es del mismo 
tipo que un miembro de una union, puede hacerse casting explfcito al tipo de 
la union. El Listado 2.13 muestra un ejemplo en el que un tipo double es 
convertido en un tipo union, asignando sus 8 bytes a la union. 



/* castunion.c */ 

#include <stdio.h> 
#include <math.h> 

union Partes 
{ 

unsigned char byte [8]; 
double dbl; 
}; 

int main (int argc, char* argv [ ] ) 
{ 

double valor = M_PI; 
union Partes p; 
p = (union Partes) valor; 
return 0; 
} 

Listado 2.13: Ejemplo de casting a un tipo union 
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Tengase en cuenta que la conversion solo se permite de tipo fundamental a 
union, no en el sentido contrarfo, es decir, la siguiente sentencia fallara: 

valor = (double) p; 



4. Warnings 



En general siempre se recomienda prestar atencion a los warnings y 
eliminarlos del programa. Esto se debe a que todo programa que produce un 
warning puede ser reescrito de forma que el warning no se produzca y se 
consiga el mismo o mayor rendimiento. 

El compilador de GCC por defecto no emite todos los mensajes de warning 
que es capaz de detectar. Esto se debe a que por defecto las GCC compilan C 
siguiendo el estandar gnu8 9 el cual es bastante tolerante con los warnings. Si 
pasamos al modo gnu99 (o c99), usando la opcion -std=gnu99 (o - 
std=c9 9), veremos que el numero de warnings generado aumenta 
apareciendo nuevos warnings que la version gnu8 9 habfa dejado pasar. En 
cualquier caso no es necesario cambiar de estandar, basta con usar la 
recomendable opcion de Ifnea de comandos -wall, la cual hace que se 
produzcan los warnings mas importantes que las GCC son capaces de 
detectar. 



Como ejemplo de la idoneidad de usar esta opcion, el Listado 2.14 muestra 
un programa que aparentemente esta bien hecho. 



/* programaseguro . c */ 




#include <stdio.h> 




int main(int argc, char* argv [ ] ) 




{ 

printf("2.0 y 2.0 son %d\n",4.0); 
return 0; 





Listado 2.14: Programa con bug 



Cuando compilamos el programa anterior no obtenemos mensajes de error, 
pero al irlo a ejecutar obtenemos un mensaje inesperado: 

$ gcc programaseguro . c -o programaseguro 
$ programaseguro 

2.0 y 2.0 son 1074790400 

Si el programa anterior lo hubieramos compilado con la opcion -wail el bug 
se hubiera detectado: 
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$ gcc programaseguro . c -Wall -o programaseguro 

programaseguro . c : In function "main': 

programaseguro . c : 8 : warning: int format, double arg (arg 2) 

Es decir, en la cadena de formato deberfamos haber usado la opcion %if 
(numero en punto flotante largo) en vez de %d (entero decimal). Este 
pequeno ejemplo muestra la importancia de usar siempre en nuestros 
programas la opcion -wail (que a partir de ahora vamos a empezar a usar). 

Si queremos ser estrictos, podemos usar la opcion -werror para que 
cualquier warning sea considerado un error y no permita compilar el 
programa. 

La opcion -wail abarca muchos, pero no todos los posibles warnings que 
pueden detectar las GCC, aunque si que abarca los warnings que es mas 
recomendable siempre controlar. La Tabla 2.7 muestra los mensajes de 
warning que incluye la opcion -wail, y la Tabla 2.8 muestra otros mensajes 
de warning que no incluye la opcion -wall. 



Warning 


Descriocion 


-Wcomment 


Esta opcion avisa de comentarios tipo C anidados, los 
cuales son causa frecuente de error. Por ejemplo: 

/* Probando a comentar esta instruccion 
double x = 1.23; /* Coordenada x */ 
*/ 


Una forma mas segura de comentar secciones con 
comentarios tipo C es usar tifdef o ... #endif de la 
forma: 

#ifdef 0 

double x = 1.23; /* Coordenada x */ 


-Wf ormat 


Esta opcion hace que se avise de errores en el formato de 
funciones como printf o , usada en el Listado 2.14. 


-Wunused 


Avisa cuando hay variables declaradas que no se usan. 


-Wimplicit 


Avisa si llamamos a funciones que no tienen prototipo 
declarado. 


-Wre turn- type 


Avisa cuando una funcion no tiene declarado en su 
prototipo un tipo de retorno (en cuyo caso por defecto es 
int), o cuando hemos olvidado retornar con return el 
valor de una funcion con retorno declarado distinto de 

void. 



Tabla 2.7: Warnings incluidos en -wail 
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Warning 


Description 


-Wconversion 


Avisa cuando se realiza una conversion de tipos, por 
ejemplo: 








No es considerado un warning por -wail, pero si usando la 

Opcion -Wconversion. 


— Ta7q -j rrn — 

no -Lull 

compare 


Avisa si se estan cornparando valores con signo con valores 
sin signo. Por ejemplo: 




int a = 3 ; 
unsigned int b = 3; 
if (a==b) 

printf ("Son iguales\n") ; 




La comparacion no producirfa un warning usando -wail, 

pero Si USandO -Wsign-compare. 


-Wshadow 


|— , m f || || ■ r | ■■■ ■ 

Esta opcion avisa sobre la redeclaracion de variables con el 
mismo nombre en dos ambitos, por ejemplo, en el 
siguiente ejemplo y esta declarada en dos ambitos, lo cual 
puede resultar lioso y conducir a errores. 




double Prueba (double x) 




{ 

double y = 1.0; 
{ 

double y; 
y = x; 






} 

return y; 

} 


-Wwrite- 
string 


Esta opcion avisa si intentamos escribir en una cadena. El 
estandar ISO no define cual debe ser el resultado de 
modificar una cadena, y escribir sobre estas esta 
desaconsejado. 


-Wmissing- 
prototypes 


Avisa si una funcion no estatica es implementada sin haber 
declarado previamente su prototipo. A diferencia de - 
wimpiicit el warning se produce aunque la funcion 
declare su prototipo en la implementacion. Esto ayuda a 
detectar funciones que no estan declaradas en ficheros de 
cabecera. 


-Wtraditional 


Avisa sobre usos de C anteriores al estandar ANSI/ISO 89 
que estan desaconsejados (por ejemplo funciones sin 
parametros). 



Tabla 2.8: Warnings no incluidos en -wall 
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5.Cambiar la version de las GCC 



Actualmente podemos tener instaladas varias versiones de las GCC. Esto 
permite compilar aplicaciones que compilaban bien con una version de las 
GCC, pero debido a cambios en el lenguaje o en las librerfas de las GCC, con 
una version mas reciente el codigo fuente de la aplicacion deja de compilar 
correctamente. 

El comando gcc seiect nos permite cambiar la version que estemos usando. 
Si queremos saber cual es la version que estamos usando actualmente, 
podemos ejecutar este comando sin parametros: 

$ gcc_select 

Current default compiler: 

gcc version 4.0.1 (Apple Computer, Inc. build 5247) 

Para saber que versiones tenemos instaladas podemos usar la opcion -1 (o 

--list): 

$ gcc_select -1 

Available compiler versions: 

3.3 3.3-fast 4.0 

Para cambiar a otra version podemos indicar al comando a version a usar: 

$ sudo gcc_select 3 . 3 

Default compiler has been set to: 

gcc version 3.3 20030304 (Apple Computer, Inc. build 1819) 
$ gcc_select 

Current default compiler: 

gcc version 3.3 20030304 (Apple Computer, Inc. build 1819) 

Actualmente tanto gcc como los demas comandos de las GCC son enlaces 
simbolicos a ficheros donde se implementa la version actual del compilador. 
Por ejemplo gcc es un enlace simbolico a gcc-3.3 0 gcc-4.0 dependiendo 
de la version que tengamos actualmente elegida. Podemos preguntar a 
gcc seiect que ficheros modifica al cambiar a una version con la opcion -n. 
Esta opcion no modifica la version actual de las GCC, tan solo indica los 
ficheros que se modificarfan: 

$ gcc_select -n 3.3 

Commands that would be executed if "-n" were not specified: 
rm -f /usr/bin/gcc 
In -sf gcc-3.3 /usr/bin/gcc 
rm -f /usr/share/man/manl/gcc . 1 
In -sf gcc-3.3.1 /usr/share/man/manl/gcc . 1 
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6.Resoluci6n de problemas 



Podemos obtener una ayuda en Ifnea sobre las opciones soportadas por el 
comando gcc usando el comando: 

$ gcc --help 

Este comando solo nos muestra las principales opciones, si queremos una 
descripcion detallada de todas las opciones del comando gcc podemos usar: 

$ gcc -v --help 

La opcion -v tambien resulta muy util para seguir los pasos que sigue el 
driver para generar un programa. Muchas veces esto nos ayuda a identificar 
el punto exacto donde falla la compilacion. A continuacion se muestra el 
resultado de ejecutar este comando en la maquina del autor: 

$ gcc -v hola.c 

Using built-in specs. 

Target: powerpc-apple-darwin8 

Configured with: /private/var/tmp/gcc/gcc- 

502 6 . ob j ~1 9/src/conf igure --disable-checking --pref ix=/usr -- 
mandir=/share/man --enable-language s=c, obj c, C++, obj -C++ -- 
program-transf orm-name=/ A [eg] [ A + . -] *$/s/$/-4 . 0 / --with-gxx- 
include-dir=/ include/ gcc/ darwin/ 4.0/ C++ --build=powerpc-apple- 
darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple- 
dar win8 

Thread model: posix 

gcc version 4.0.0 (Apple Computer, Inc. build 5026) 
/usr/libexec/gcc/powerpc-apple-darwin8/4 . 0 . 0/ccl -guiet -v - 

D DYNAM IC hola.c -fPIC -guiet -dumpbase hola.c -auxbase 

hola -version -o / var/tmp//ccFHi4To . s 

#include search starts here: 

#include <...> search starts here: 
/usr/ local/ include 

/usr/lib/ gcc /powerpc-apple -darwin 8/ 4.0.0/ include 
/ usr/ include 

/ System/Library/Frameworks 
/Library /Frameworks 
End of search list. 

GNU C version 4.0.0 (Apple Computer, Inc. build 5026) 
( powerpc-apple -darwin 8 ) 

compiled by GNU C version 4.0.0 (Apple Computer, Inc. build 
5026) . 

as -arch ppc -o /var/tmp//ccozRXSa . o /var/tmp//ccFHi4To . s 

/ usr/libexec/ gcc /powerpc-apple -darwin 8/ 4. 0.0/ collect 2 - 
dynamic -arch ppc -weak_ref erence_mismatches non-weak -o a . out 
-lcrtl.o /usr/lib/gcc/powerpc-apple-darwin8/4 . 0 . 0/crt2 . o - 
var/tmp//ccozRXSa . o -lgcc -lgcc_eh -lSystemStubs -lmx -lSystem 



Pag 39 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 



Tema 3 

Crear y usar 
lib re lias 



Sinopsis: 



Las librenas nos permiten agrupar grandes cantidades de codigo en un solo 
fichero reutilizable desde otros programas. En este tema vamos a estudiar 
tanto la creacion como el uso de librenas. 

El tema empieza detallando como crear y usar librenas de enlace estatico, 
despues haremos el mismo recorrido sobre las librenas de enlace dinamico, y 
por ultimo veremos los frameworks, un tipo de librenas de enlace dinamico en 
las que junto a la librena de enlace dinamico encontramos otros recursos. 
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l.Librerias de enlace estatico 

Una librena de enlace estatico, tambien llamada librena estatica o 
archivo, es un conjunto de ficheros . o generados por el compilador como 
normalmente. Enlazar un programa con un fichero de codigo objeto de la 
librarfa es equivalente a enlazarlo con un fichero de codigo objeto en el 
directorio. 

A las librerfas de enlace estatico tambien se las llama archivos porque el 
comando usado para generarlas es ar, como vamos a ver a continuacion. 



1 .1 . Creadon y uso de librerfas de enlace estatico 

Para construir una librena primero necesitamos compilar los modulos en 
ficheros de codigo objeto. Como ejemplo vamos a usar los ficheros de codigo 
fuente del Listado 3.1 y Listado 3.2. 



/* saludol.c */ 

#include <stdio.h> 

void Saludol ( ) 
{ 

printf("Hola por primera vez\n") ; 



Listado 3.1: Funcion que saluda una vez 



/* saludo2.c */ 

#include <stdio.h> 

void Saludo2 ( ) 
{ 

printf("Hola de nuevo\n"); 



Listado 3.2: Funcion que saluda de nuevo 

Para obtener los ficheros de codigo objeto correspondientes usamos el 
comando: 

$ gcc saludol.c saludo2.c -c 

Ahora podemos usar el comando ar con la opcion -r (replace and add) para 
crear un archivo con los ficheros de codigo objeto dentro de el. El comando, 
crea el archivo si no existe, y anade (o reemplaza si existen) los ficheros 
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indicados. Por ejemplo, para crear el fichero libsaiudos. a usamos el 
comando: 

$ ar -r libsaiudos . a saludol . o saludo2 . o 

ar: creating archive libsaiudos . a 

La librerfa ya esta lista para ser usada. El Listado 3.3 muestra un programa 
que usa la librerfa. 



/* saludos.c */ 

void Saludol ( ) ; 
void Saludo2 ( ) ; 

main ( ) 
{ 

Saludol () ; 
Saludo2 () ; 
return 0; 

J 

Listado 3.3: Programa que ejecuta las funciones de la librerfa 

Para compilar el programa del Listado 3.3 junto con la librerfa podemos usar 
el comando: 

$ gcc saludos . c libsaiudos . a -o saludos 

Si la librerfa hubiera estado en otro directorio, hubiera bastado con indicar la 
ruta completa del fichero de librerfa. 

Aunque no es estrictamente obligatorio, si queremos usar la opcion del 
enlazador -1 para indicar librerfas con las que enlazar el programa, los 
ficheros de las librerfas estatica deben tener un nombre que empiece por lib 
y acabar en .a. Si los ficheros siguen esta convencion podemos acceder a 
ellos de la forma: 

$ gcc saludos.c -lsaludos -o saludos 

Id: can't locate file for: -lsaludos 

En este caso el comando enlazador id ha buscado un fichero llamado 
libsaiudos . a, pero no lo ha encontrado porque no se encuentra en los 
directories reservados para almacenar librerfas, ni en la variable de entorno 

LIBRARY_PATH. 

En la mayorfa de los SO (incluido Mac OS X), los directories predefinidos para 
librerfas son, por este orden de busqueda: 

/ usr/local/lib 
/ usr/lib 
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Para copiar la librerfa a estos directories debe tener permiso de 
administrador, pero puede usar la opcion del enlazador -l (mayuscula) para 
indicar directories adicionales donde el enlazador debe buscar librerfas: 

$ gec saludos.c -L. -lsaludos -o saludos 

La opcion -l (al igual que la opcion -i) debe usarse una vez por cada 
directorio que se quiera anadir a la lista de directories de librerfas. 

Quiza le resulte mas comodo incluir el directorio actual en la variable de 
entorno library path, con el fin de no tener que usar la opcion -l siempre 
que quiera enlazar con la librerfa: 

$ export LIBRARY_PATH=$LIBRARY_PATH: . 
$ gec saludos.c -lsaludos -o saludos 

Por ultimo comentar que en Mac OS X (y en otros muchos sistemas UNIX) 
existe el comando libtooi 1 el cual nos permite crear una librerfa de enlace 
estatico (opcion -static) o de enlace dinamico (opcion -dynamic). La 
librerfa que antes generamos con el comando ar tambien la podemos generar 
con el comando libtooi de la forma: 

$ libtooi -static saludol.o saludo2.o -o libsaludos.a 

Si no pasamos opcion a libtooi por defecto asume -static, aun asf es 
recomendable indicar la opcion por claridad. 

1 .2. La tabla de sfmbolos 

En un fichero de librerfa estatica, delante de los ficheros de codigo objeto se 
almacena una tabla de simbolos, que sirve para indexar todos los sfmbolos 
globales (variables globales y funciones) de la librerfa. Antiguamente esta 
tabla de sfmbolos habfa que crearla con el comando raniib, pero 
actualmente el comando ar crea automaticamente la tabla de sfmbolos, con 
lo que el comando raniib ha pasado a marcarse como un comando obsoleto 
que se mantiene por compatibilidad. 

Cuando el enlazador elige un sfmbolo de la tabla de sfmbolos para introducir 
su codigo en el programa, el enlazador incluye todo el fichero de codigo 
objeto donde este (aunque el programa no use todo su contenido). Si ningun 
sfmbolo de un fichero de codigo objeto es usado por el programa, el 
enlazador no incluye este fichero de codigo objeto en el ejecutable. Esta 
ultima regla es importante tenerla en cuenta cuando se crear librerfas, ya que 



1 El comando libtooi que encontrara en Mac OS X lo crearon los ingenieros de Apple, y no 
es exactamente igual al comando libtooi de GNU, aunque su finalidad es semejante 
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si un fichero de codigo objeto hace llamadas a otro fichero de codigo objeto 
de la librerfa (pero el programa no hace ninguna referenda a este ultimo), el 
usuario de nuestra librerfa obtendra mensajes de error indicando que hay 
sfmbolos no resueltos durante el enlazado. 

Ya que los ficheros de codigo objeto no se enlazan si no se usan, un 
programa que use librerfas estaticas puede ocupar menos espacio que el 
correspond iente fichero enlazado directamente con los ficheros de codigo 
objeto sin empaquetar en librerfa (que siempre se enlazan aunque no se 
usen). 

Podemos usar el comando nm para ver la tabla de sfmbolos de un fichero .o o 
.a de la forma: 

$ nm saludol . o 

00000000 T _Saludol 
U _printf 

U dyld_stub_binding_helper 

En el caso de que lo hagamos sobre una librerfa (fichero .a) nos muestra los 
sfmbolos de cada fichero: 

$ nm libsaludos . a 

libsaludos . a ( saludol . o) : 
00000000 T _Saludol 
U _printf 

U dyld_stub_binding_helper 

libsaludos . a ( saludo2 . o) : 
00000000 T _Saludo2 
U _printf 

U dyld_stub_binding_helper 



1 .3. Modificar y borrar elementos de una librerfa 

Podemos ver que ficheros .o contiene una librerfa con el comando -t: 

$ ar -t libsaludos. a 

. SYMDEF SORTED 

saludol . o 
saludo2 . o 

.symdef sorted es la tabla de sfmbolos que crea ar para evitar que se 

introduzcan sfmbolos duplicados (en varios ficheros . o), y para acelerar el 
acceso a los sfmbolos por parte del enlazador. 

Tambien podemos preguntar por todos los atributos de los ficheros con la 
opcion -v (verbose): 



Pag 44 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 



$ ar -tv libsaludos.a 

rw-r — r — 503/503 48 Dec 4 21:03 2005 . SYMDEF SORTED 

rw-r — r — 503/80 816 Dec 4 17:59 2005 saludol.o 

rw-r — r — 503/80 808 Dec 4 17:59 2005 saludo2.o 

0 bien podemos extraer los ficheros de una librerfa con el comando -x 
(extract): 

$ ar -x libsaludos . a 

Que extrae todos los ficheros .o al directorio actual. O bien indicar el fichero 
a extraer: 

$ ar -x libsaludos . a saludol . o 

La operacion de extraer no borra los ficheros de la librerfa, sino que si 
queremos borrar unos determinados ficheros debemos usar la opcion -d de la 
forma: 

$ ar -d libsaludos . a saludol . o 
$ ar -t libsaludos.a 

_. SYMDEF SORTED 
saludo2 . o 

Donde hemos eliminado el fichero saludol .o de la librerfa. 



1.4. Juntar modulos 

Aunque una librerfa esta formada por modulos, a veces conviene combinar 
varios modulos de codigo objeto en uso solo, ya que la llamadas entre 
funciones de distintos modulos es un poco mas lenta que entre funciones del 
mismo modulo. Para realizar esta tarea el comando id puede recibir varios 
ficheros de codigo objeto y generar otro con los modulos agrupados en uno 
solo. Si hacemos esto es importante acordarse de usar la opcion -r para que 
se conserve la informacion del modulo objeto necesaria para que este puede 
luego volver a ser enlazado, ya que id elimina por defecto esta informacion 
de su salida, a la que se llama informacion de reasignacion. 

En el ejemplo anterior vemos que si preguntamos por la composicion del 
fichero usando el comando nm obtenemos: 

$ nm libsaludos . a 

libsaludos . a ( saludol . o) : 
00000000 T _Saludol 

U _printf $LDBLStub 

U dyld_stub_binding_helper 
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libsaludos . a ( saludo2 . o) : 
00000000 T _Saludo2 

U _printf $LDBLStub 

U dyld_stub_binding_helper 

Si ahora combinamos los ficheros de codigo objeto saiudoi.o y saiudo2.o 
en uno solo: 

$ Id -r saludol . o saludo2 . o -o saludol2 . o 

Y volvemos a generar la librerfa, la nueva librerfa estara formada por un solo 
modulo: 

$ $libtool -static saludol2.o -o libsaludos. o 
$ $nm libsaludos . o 

libsaludos . o ( saludol2 . o) : 
00000000 T _Saludol 
0000003c T _Saludo2 

U _printf $LDBLStub 

U dyld_stub_binding_helper 
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2.Librerias de enlace dinamico 



Una libreria de enlace dinamico, tambien llamada libreria compartida, 

contiene ficheros de codigo objeto que se cargan en memoria, y se enlazan 
con el programa, cuando el programa que usa sus funciones accede a una de 
ellas por primera vez. 

La forma de funcionar de las librerfas de enlace dinamico tiene dos ventajas 
sobre las librerfas de enlace estatico: Por un lado la misma libreria puede 
estar cargada en memoria una vez y compartida por varias aplicaciones, lo 
cual reduce el consumo de memoria 1 . Esta es la razon por la que tambien se 
llaman librerfas compartidas. Por ejemplo, el Foundation y el Application 
framework son librerfas de enlace dinamico compartidas por todas las 
aplicaciones Cocoa. La segunda ventaja es que las aplicaciones se actualizan 
automaticamente cuando se actualizan las librerfas. Por ejemplo, si una 
librerfa tenia un bug por el que una funcion fallaba o tenia grandes retrasos, 
si la funcion se arregla, o optimiza, la aplicacion se aprovecha de esta mejora. 

Tambien esta forma de funcionar tiene dos inconvenientes: El primero es que 
como la librerfa tiene que cargarse, y enlazarse al programa, la primera vez 
que se usa un sfmbolo de la librerfa, el programa sufre pequenas paradas 
(latencias) en mitad de su ejecucion, y el segundo inconveniente es que 
cuando se actualizan las librerfas de enlace dinamico, si no se hace con 
cuidado 2 pueden producirse errores en los programas antiguos que las usen. 

2.1. Como funcionan las librerfas de enlace dinamico 

Cuando se ejecuta una aplicacion, el nucleo de Mac OS X carga el codigo y 
datos de la aplicacion en el espacio de memoria del nuevo proceso. El nucleo 
ademas carga el llamado cargador dinamico (dynamic loader) 

(/usr/iib/dyid) en la memoria del proceso, y pasa el control a este. En 
este momento el cargador dinamico carga las librerfas de enlace dinamico que 
el programa utilice. Durante el proceso de enlazado de la aplicacion el 
enlazador estatico, es decir el comando id, guardo dentro de la aplicacion las 
rutas de las librerfas de enlace dinamico que utilizaba. Si el cargador dinamico 
detecta que alguna de las librerfas de las que depende el ejecutable falta, el 
proceso de arranque de la aplicacion falla. 



1 Las librerfas de enlace dinamico se mapean en memoria en el modo copy-on-write de forma 
que el segmento de codigo siempre es compartido por todas las aplicaciones que usen la 
librena. Si una libreria escribe en el segmento de datos, se crea otra copia de este segmento 
para la aplicacion, y todas las demas aplicaciones siguen usando el anterior segmento de 
datos. 

2 En el apartado 2.2 veremos que siguiendo unas sencillas reglas estos problemas nunca se 
produciran. 
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Como veremos, el programador tambien puede decidir no usar el cargador 
dinamico para cargar las librerfas de enlace dinamico automaticamente 
durante el arranque de la aplicacion, sino cargarlas solo cuando pasemos por 
el trozo del programa que las usa. Para ello, veremos que se usan funciones 
de la familia diopen o . Esto permite acelerar el proceso de arranque de las 
aplicaciones, y evita cargar en memoria librerfas que no vamos a usar, 
aunque requiere mas trabajo por parte del programador. 

2.2. Compatibilidad entre versiones 

2.2.1. Compatibilidad hacia atras y hacia adelante 

Desde el punto de vista de la aplicacion que usa una librerfa de enlace 
dinamico existen dos tipos de compatibilidad que conviene concretar. 

Se dice que una librerfa es compatible hacia atras (o que suplanta a una 
version anterior) cuando podemos cambiar la librerfa y las aplicaciones 
enlazadas con la antigua librerfa siguen funcionando sin modificacion. Para 
conseguir compatibilidad hacfa atras debemos de mantener tanto las 
funciones antiguas como las nuevas. 

Se dice que una librerfa es compatible hacia adelante (o que suplanta a 
una version posterior) cuando es capaz de ser usada en lugar de versiones 
posteriores de la librerfa, y las aplicaciones enlazadas con librerfas futuras 
siguen pudiendo enlazar con la librerfa actual. Logicamente la compatibilidad 
hacia adelante es mas diffcil de conseguir porque la librerfa tiene que predecir 
que cambios se haran en el futuro en la librerfa. 

2.2.2. Versiones mayores y menores 

Existen dos tipos de revisiones que se pueden hacer a una librerfa: Revisiones 
que son compatibles con las aplicaciones clientes, es decir, que no requieren 
cambios en las aplicaciones clientes, y revisiones que requieren que las 
aplicaciones cliente se vuelvan a enlazar con la nueva librerfa de enlace 
dinamico. Las primera son las llamadas versiones menores (minor 
versions), y las segundas las versiones mayores (mayor versions). 

Las versiones mayores se producen cuando necesitamos modificar algun 
aspecto de la librerfa que impliquen eliminar sfmbolos publicos de la librerfa o 
cambiar los parametros o el funcionamiento de alguna funcion de librerfa. 

Las versiones menores se producen cuando arreglamos algun bug que hacfa 
fallar a la aplicacion, mejoramos el rendimiento de las funciones, o ahadimos 
nuevos sfmbolos que la version anterior no tenfa. 
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Los nombres de las librerfas de enlace dinamico suelen empezar por lib y 
acabar en .dyiib 1 , es decir, tienen la forma libxxx.dyiib donde solo xxx 
es variable. Cuando realizamos una version mayor debemos cambiar el 
nombre de la librerfa incluyendo el nuevo numero de version mayor en el 
nombre de la librerfa. Por ejemplo si tenemos el fichero 
libsaiudos . a. dyiib, y hacemos una version mayor el siguiente fichero 
podrfa ser libsaiudos .b. dyiib. La forma de numerar las librerfas no esta 
estandarizada, podrfan por ejemplo haberse llamado libsaiudos . 1 . dyiib y 

libSaludos . 2 . dyiib. 

Para facilitar el cambio de version mayor es muy tfpico crear un enlace 
simbolico de la forma libsaiudos . dyiib que apunte a la ultima version 

mayor (p.e. libSaludos .B. dyiib). 

Logicamente crear versiones mayores consume mas espacio en disco, y es 
algo que debe de intentar evitarse en la medida de lo posible. 

Cuando se enlaza un programa con una librerfa, el enlazador estatico guarda 
dentro del ejecutable el path de la librerfa al que apunta el enlace simbolico. 
El cargador dinamico usa este path durante el arranque de la aplicacion para 
encontrar la version mayor de la librerfa. Luego las versiones mayores sirven 
para que la librerfa pueda tener compatibilidad hacia atras, de forma que al 
actualizar la librerfa los programas que enlazaban con el anterior fichero de 
librerfa sigan funcionando. 

Dentro de la version mayor de una librerfa podemos designar tambien 
numeros de version, que son numeros incrementales de la forma x[.y[.z] ], 
conde x es un numero entre 0 y 65535, y y, z son numeros entre 0 y 255. 
Cada fichero de version mayor tiene dos numeros de version menor: El 
numero de version actual y el numero de version de compatibilidad. 
La union de estos dos numeros es lo que llamaremos la version menor. 
Dentro de una version mayor solo puede haber una version menor, una 
nueva version menor simplemente sobrescribe un numero de version anterior. 
Esto difiere del esquema de las versiones mayores, donde muchas versiones 
mayores pueden coexistir (en distintos ficheros). 

Cada vez que actualizamos cualquier aspecto de la librerfa debemos de 
cambiar el numero de version actual. Por contra, el numero de version de 
compatibilidad solo se cambia cuando cambiamos la interfaz publica de la 
librerfa (p.e. anadiendo una clase o una funcion). En este caso el numero de 
version de compatibilidad debe ponerse al mismo valor que el numero de 
version actual. En caso de que el cambio sea solo arreglar un bug o mejorar 
el rendimiento de la librerfa, pero no modifiquemos la interfaz publica, solo 



1 Esto es una peculiardad de Mac OS X, en la mayoria de los sfstemas UNIX las librerfas de 
enlace dinamico tienen la extension .soy funcionan de forma ligeramente diferente. Mac OS 
X tambien soporta la extension . so por compatibilidad. 
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debemos actualizar el numero de version actual. Luego el numero de version 
de compatibilidad es un numero que indica el numero de version actual mas 
antigua con la que la aplicacion cliente que enlaza con nuestra librerfa puede 
ser enlazada al ser ejecutada la aplicacion. 

Para indicar a gcc el numero de version actual se usa la opcion del 
compilador - current version cuando enlazamos la librerfa. Para indicar el 
numero de version de compatibilidad se usa la opcion -compatibility 
version cuando enlazamos la librerfa. Por ejemplo, si nuestro numero de 
version actual de la librerfa es -current version 1.2, y el numero de 
version de compatibilidad es -compatibiiity_version 1.1, indicamos que 
las aplicaciones clientes no pueden ser enlazadas con versiones anteriores a 
la 1.1. 

Hay que tener en cuenta que las versiones menores siempre son compatibles 
hacia atras, 0 de lo contrario deberfamos de haber actualizado el numero de 
version mayor. Ademas utilizando inteligentemente las versiones menores 
podemos conseguir ademas la compatibilidad hacia adelante. 

En principio el numero de version actual no es suficiente para garantizar la 
compatibilidad hacfa adelante, es decir, una aplicacion que esta enlazada por 
el enlazador estatico con la version actual 1.1, va a funcionar si al ejecutarla 
el cargador dinamico la enlaza con la version actual 1.2, pero al reves no 
tiene porque ser necesariamente cierto, ya que la version actual 1.2 puede 
tener nuevas funciones que la version actual 1.1 no tenga. 

Para conseguir compatibilidad hacfa adelante se usa la version de 
compatibilidad. Cuando el enlazador estatico asocia una librerfa con la 
aplicacion, almacena en la aplicacion el numero de version de compatibilidad 
de la librerfa. Antes de cargar la librerfa de enlace dinamico el cargador 
dinamico compara la version menor actual de la librerfa existente en el 
sistema de ficheros del usuario, con la version de compatibilidad del fichero 
de librerfa con la que fue enlazada la aplicacion. Si la version actual de la 
librerfa es menor a la version de compatibilidad guardada en la aplicacion, la 
carga de la librerfa falla. Los casos en los que una librerfa es demasiado 
antigua no son comunes pero tampoco imposibles. Ocurren cuando el usuario 
intenta ejecutar la aplicacion en un entorno con una version antigua de la 
librerfa. Cuando esta condicion ocurre, el cargador dinamico detiene la carga 
de la aplicacion y da un mensaje de error en consola. 

El comando cmpdyiib se puede usar para comprobar si dos librerfas de 
enlace dinamico son compatibles entre sf. 

Es importante recordar que el cargador dinamico compara la version de 
compatibilidad de la aplicacion con la version actual de la librerfa, pero esto 
no lo hacen las funciones de la familia diopen o, que se usan para cargar 
librerfas en tiempo de ejecucion. 
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2.3. Creadon y uso de librenas 



El codigo objeto de las librenas de enlace dinamico debe ser codigo PIC 
(Position Independent Code), que es un codigo preparado para poder ser 
cargado en cualquier posicion de memoria, lo cual significa que todas las 
direcciones de todas sus sfmbolos globales (variables y funciones) debe de 
ser relativas, y no absolutas, con el fin de que la librerfa pueda ser cargada y 
sus sfmbolos accedidos en tiempo de ejecucion. En el apartado 2.10 
detallaremos mejor este proceso. 

Como muestra la Figura 3.1, el programa que se encarga de cargar en 
memoria un ejecutable y ponerlo en ejecucion es el cargador dinamico, su 
nombre proviene de que no solo es capaz de cargar en memoria ejecutables, 
sino que tambien sabe cargar librenas dinamicas. 



Pila 



Cargador dinamico 



Librerfa de 
enlace dinamico 



Heap 



Librerfa de 
enlace dinamico 



Codigo de la aplicacion 



Figura 3.1: Carga de una librena de enlace dinamico en la memoria del proceso 



Para generar este tipo de codigo se usa la opcion -fpic 1 . Explicados estos 
conceptos, vamos a ver como se crear librerfas de enlace dinamico, para lo 
cual vamos a volver a usar los ficheros del Listado 3.1 y del Listado 3.2. 
Empezamos compilando el codigo fuente en ficheros de codigo objeto PIC con 
el comando: 



$ gcc -c -fPIC saludol.c saludo2 . c 



Para ahora enlazar la librerfa compartida debemos usar la opcion - 

dynamiciib de la forma: 



1 En el caso de Mac OS X la opcion -f Pic no es necesaria ya que por defecto el driver pone 
esta opcion en todos los ficheros que compila. 
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$ gcc -dynamic lib saludol.o saludo2.o -o libSaludos . dylib 

Ya solo nos queda llamar a la librerfa desde un programa como el del Listado 
3.3. Para ello podemos simplemente enlazar el ejecutable con la librerfa 
usando: 

$ gcc saludos.c libSaludos .dylib -o saludos 

Podemos ver las librerfas de enlace dinamico de que depende nuestro 
ejecutable con el comando otooi y la opcion -l 1 : 

$ otool -L saludos 

saludos : 

libSaludos . dylib (compat ver 0.0.0, current ver 0.0.0) 
/usr/lib/libmx . A . dylib (compat ver 1.0.0, current ver 
92.0.0) 

/usr/lib/libSystem . B . dylib (compat ver 1.0.0, current ver 
88.1.2) 

Como ya sabemos, gcc es un driver que se encarga de llamar a los comandos 
adecuados para generar el ejecutable o librerfa deseados. La opcion - 
dynamiciib de gcc lo que produce es, que en vez de ejecutarse el enlazador 
estatico (comando id), se ejecute el comando libtooi -dynamic, el cual 
produce la librerfa de enlace dinamico. Es decir la librerfa anterior tambien la 
podrfamos haber generado con el comando: 

$ libtooi -dynamic saludol.o saludo2.o -lSystemStubs -lSystem 
-o libSaludos . dylib 

Aun asf resulta mas conveniente usar el comando gcc, ya que este se 
encarga de pasar a libtooi las opciones adecuadas. Por ejemplo, gcc sabe 
que al llamar a libtooi le debe pasar las opciones -lsystemstubs y - 
lsystem para que enlace correctamente con las librerfas que usa nuestro 
programa, con lo que gcc nos resuelve el problema de forma transparente. 

2.3.1. Dependencias entre librerias 

Cuando creamos una librerfa de enlace dinamico que usa otras librerfas de 
enlace dinamico, los nombres de las librerfas de las que depende nuestra 
librerfa se guardan como nombres de instalacion dentro de nuestra librerfa. 
Cuando una aplicacion usa nuestra librerfa, no solo se carga nuestra librerfa, 
sino tambien las librerfas de las que nuestra librerfa depende. Al igual que con 
la aplicacion, podemos ver las librerfas de enlace dinamico de las que 
depende una librerfa con el comando otooi -l. 



1 En los sistemas UNIX tradicionales se usa idd para encontrar las dependencias. Por contra 
en Mac OS X no existe este comando sino que en su lugar se usa otooi -l. 
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Tenga en cuenta que logicamente, la carga de las librerfas de enlace dinamico 
por parte del cargador dinamico durante el arranque de la aplicacion 
enlentece el arranque. Si estamos creando una librerfa de enlace dinamico (o 
aplicacion) que usa una librerfa de enlace dinamico en escasas ocasiones, 
quiza serfa bueno que se plantease el uso de las funciones de la familia 
diopen o que se explican en el apartado 2.5. 

Aunque la imagen de las librerfas es cargada en memoria (por parte del 
cargador dinamico) durante el arranque de la aplicacion, como muestra la 
Figura 3.1, las referencias a los sfmbolos exportados utilizan enlace tardio 
(lazy binding), que significa que la direccion del sfmbolo no es resuelta 
hasta que se vaya a usar por primera vez. En el apartado 2.8 se describe con 
mas detalle este proceso. 

2.4. Instalar la librerfa 

En este apartado vamos a ver como hace el cargador dinamico para buscar 
las librerfas de enlace dinamico. 



2.4.1. El nombre de instalacion 

Las librerfas de enlace dinamico tienen un nombre de instalacion, que 

indica en que ruta va a estar instalado el fichero de la librerfa cuando lo vayan 
a usar las aplicaciones. 

Al ejecutar otooi en el apartado anterior podemos ver que la librerfa 
libsaiudos .dyiib no tiene ruta de instalacion, lo cual significa que debe de 
estar instalada en el mismo directorio que la aplicacion. Debido a que la 
finalidad de las librerfas es ser usadas por varias aplicaciones lo normal es 
que la librerfa se encuentre en un directorio de librerfa (tfpicamente 
/usr/iib, /usr/iocai/iib o ~/iib), y que varias aplicaciones enlacen con 
esa misma ruta. 

Para indicar el nombre de instalacion se usa la opcion -instaii name como 
muestra el siguiente ejemplo: 

$ gcc -dynamiclib saludol.o saludo2.o -install_name /usr/local 
/lib/ libSaludos .dylib -o libSaludos . dylib 

El nombre de instalacion se almacena dentro del fichero de librerfa, y tambien 
se almacena dentro del fichero de la aplicacion cliente con el fin de que el 
cargador dinamico pueda acceder a este fichero cuando la aplicacion se 
ejecute. 

Podemos obtener el nombre de instalacion de una librerfa con la opcion -d de 

otooi: 
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$ otool -D libSaludos .dylib 

/ us r/ local /lib/ libSaludos . dylib 

Si ahora volvemos a compilar la aplicacion, y volvemos a preguntar a otool 
por las librerfas de enlace dinamico de la aplicacion: 

$ gcc saludos.c libSaludos .dylib -o saludos 
$ otool -L saludos 

saludos : 

/usr/local/lib/libSaludos . dylib (compat ver 0.0.0, 
current ver 0.0.0) 

/usr/lib/libmx . A . dylib (compat ver 1.0.0, current ver 
92 . 0 . 0) 

/usr/lib/libSystem . B . dylib (compa ver 1.0.0, current ver 
88.1.2) 

Obtenemos el nombre de instalacion como una ruta absoluta. Pero si ahora 
intentamos ejecutar la aplicacion: 

$ saludos 

dyld: Library not loaded: /usr/local/lib/libSaludos . dylib 
Reason: image not found 
Trace/BPT trap 

Su ejecucion falla ya que ahora busca la librerfa en la ruta de su nombre de 
instalacion, y no en el directorio actual. Logicamente siempre podemos copiar 
la librerfa en la ruta de su nombre de instalacion, y poder asf ejecutar la 
aplicacion: 

$ sudo cp libSaludos .dylib /usr/local/lib 
$ saludos 

Hola por primera vez 
Hola de nuevo 



2.4.2. Proceso de busqueda de librerias 

El proceso que sigue el cargador dinamico para buscar librerias de enlace 
dinamico es el siguiente: 

Cuando el nombre de instalacion de la librerfa es una ruta relativa (p.e. 
libSaludos . dylib), el cargador dinamico busca las librerfas a cargar en 
este orden: 

1. En los directories indicados por la variable de entorno 

$ LD_L I BRARY_PATH . 

2. En los directorios indicados por la variable de entorno 

$DYLD_LIBRARY_PATH. 

3. En el directorio de trabajo de la aplicacion. 
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4. En los directorios indicados por la variable de entorno 

$DYLD_FALLBACK_LIBRARY_PATH. 

Por contra, cuando el nombre de instalacion de la librerfa es una ruta absoluta 
(p.e. /usr/iocai/iib/iibsaiudos .dyiib), el cargador dinamico busca las 
librerfas a cargar en este otro orden: 

1. En los directorios indicados por la variable de entorno 

$DYLD_LIBRARY_PATH. 

2. En la ruta dada por el nombre de instalacion. 

3. En los directorios indicados por la variable de entorno 

$DYLD_FALLBACK_LIBRARY_PATH. 

Como habitualmente, las variables de entorno pueden tener la ruta de uno o 
mas directorios de busqueda separados por dos puntos. Por defecto estas 
variables no tienen valor asignado, aunque el administrador puede fijar estas 
variables en scripts de arranque para buscar librerfas en directorios no 
estandar. 

La variable de entorno $ld_library_path es la recomendada para las 
librerfas con extension .so, que es la extension usada por la mayorfa de los 
sistemas UNIX. Por contra $dyld_library_path es la recomendada para las 
librerfas con extension .dyiib. 

Apple recomienda usar librerfas con la extension .dyiib, aunque esto no es 
obligatorio sino opcional. En Mac OS X existe la opcion de gcc no estandar - 
instaii name para poder guardar el nombre de instalacion con la ruta 
relativa o absoluta de la librerfa. El uso de esta opcion acelera el proceso de 
carga de la librerfa, ya que el cargador dinamico no tiene que buscar la 
librerfa, sabe exactamente donde se encuentra el fichero. 

En los sistemas UNIX tradicionales no existe el nombre de instalacion y se 
buscan librerfas de enlace dinamico en los directorios por defecto (que son 
/usr/iib y /usr/iocai/iib), y despues en los directorios indicados por la 
variable de entorno $ld_library_path. Para mantener compatibilidad con 
estos casos, y con los casos en los que el programador de la librerfa no indica 
un nombre de instalacion (usando la opcion -instaii name) existen las 
reglas de busqueda en ruta relativa. 

El orden en el proceso de busqueda de librerfas es importante porque si un 
mismo sfmbolo esta definido en dos librerfas, el cargador dinamico cargarfa la 
primera librerfa que usase este sfmbolo. Por ello es recomendable al crear 
librerfas poner a todos los sfmbolos publicos un prefijo que evite conflictos 
con sfmbolos de otras librerfas. En el caso de las funciones de la familia 
diopen o , existen opciones para poder buscar todas las librerfas que definen 
un sfmbolo. 
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Otra informacion importante que se almacena en las librerfas es la version 
requerida de las librerfas de que dependa. En tiempo de ejecucion el cargador 
dinamico comprobara que las versiones de las librerfas cargadas sean 
correctas. 



2.5. Carga de librerfas en tiempo de ejecucion 

Normalmente cada sistema UNIX implementa la carga dinamica de librerfas 
de enlace dinamico de forma diferente. Esto ha dificultado la portabilidad de 
aplicaciones entre sistemas UNIX. Para facilitar la portabilidad de librerfas de 
enlace dinamico Jorge Acereda y Peter O'Gorman desarrollaron un conjunto 
de funciones llamadas Dynamic Loader Compatibility (DLC). En concrete 
se trata de cinco funciones definidas en el fichero /usr/inciude/difcn.h, y 
que se resumen en la Tabla 3.1. 



Funcion 


Description 


dlopen ( ) 


Abre una librerfa de enlace dinamico. Una aplicacion debe 
llamar a esta funcion antes de usar cualquier sfmbolo 
exportado de la librerfa. Si la librerfa no esta abierta por el 
proceso llamante, la librerfa se carga en la memoria del 
proceso. La funcion retorna un handle que usaran disymo y 
diciose o . La funcion mantiene la cuenta del numero de 
veces que se ha pedido abrir cada librerfa. 


dlclose ( ) 


Usado por el proceso para cerrar el handle. Si diopen o se 
ha llamado varias veces, esta funcion debera ser llamada el 
mismo numero de veces. En caso de que la librerfa fuera 
cargada en memoria por diopen o (y no por el cargador 
dinamico), la ultima llamada a diciose o descarga la 
librerfa de enlace dinamico de la memoria del proceso. 


dlsym ( ) 


Retorna la direccion de un sfmbolo exportado por una 
librerfa de enlace dinamico. 


dladdr () 


Recibe una direccion de memoria y, si esta corresponde con 
la direccion de memoria de una variable o funcion de la 
librerfa, devuelve informacion sobre este sfmbolo en una 
variable de tipo Di inf o con informacion sobre la variable o 
funcion. 


dlerror ( ) 


Devuelve una cadena con una descripcion del error 
producido en la ultima llamada a diopen ( ) , disym ( ) o 

dladdr () . 



Tabla 3.1: Funciones de DLC 



El Listado 3.4 muestra como podemos cargar la librerfa libsaiudos .dyiib, y 
ejecutar una funcion de esta, usando las funciones de la familia diopen o . 
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/* saludosdl.c */ 

#include <stdio.h> 
#include <dlfcn.h> 

void Saludol ( ) ; 
void Saludo2 ( ) ; 

main ( ) 
{ 

/ / Abre la libreria 

void* 1 = dlopen ("libSaludos .dylib", 0) ; 
if (1==NULL) 
{ 

printf ( "Error abriendo la libreria: %s\n" , dlerror ( ) ) ; 
return 1; 

} 

// Obtiene un puntero al simbolo de la funcion 
void (*pfn) () = dlsym(l, "Saludol") ; 
if (pfn==NULL) 
{ 

printf ( "Error buscando la funcion: %s\n" , dlerror ()) ; 
return 1; 

} 

// Ejecuta la funcion de la libreria 
pfn () ; 

/ / Cierra la libreria 
dlclose (1) ; 
return 0; 



Listado 3.4: Ejemplo de acceso a una librena con las funciones de la familia dlopen ( ) 



2.6. Encapsular la funcionalidad 

Reducir el numero de sfmbolos que una librena exporta acelera los accesos a 
la tabla de sfmbolos, y hace que la libreria sea mas facil de usar y mantener. 

Como regla general, aunque es totalmente posible hacerlo, no se recomienda 
exportar variables globales, ya que esto permitirfa al usuario asignarlas 
valores inapropiados, en vez de esto, se recomienda crear funciones get/set 
que accedan a estas variables, y que controlen los valores que se asignan. 

Otra regla de buen diseno es que si una funcion va a ser ejecutada tanto por 
los clientes de la libreria, como por la propia librena, debemos de crear una 
funcion wrapper, destinada al cliente, que controle los parametros que recibe, 
y que Name a la funcion real. Internamente la libreria puede llamar a la 
funcion real para evitar que se comprueben los valores de los argumentos, ya 
que la libreria sabra pasar solo valores correctos a la funcion. 
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2.6.1. Nombres en dos niveles 

Como hemos visto en el apartado 2.4.2, el cargador dinamico no detecta 
conflictos de nombres cuando el mismo sfmbolo es exportado por dos librerfas 
distintas, sino que carga el sfmbolo de la primera librerfa que encuentra. Para 
evitar este tipo de errores diffciles de detectar por el usuario existen dos 
soluciones: La primera es poner a todos los sfmbolos exportados un prefijo 
que identifique a la librerfa, la segunda es usar nombres de dos niveles. 

Los nombres en dos niveles fueron introducidos en Mac OS X 10.1 y 
consisten en anadir el nombre de la librerfa como parte del nombre del 
sfmbolo. Esto evita que dos sfmbolos con el mismo nombre en dos librerfas 
distintas interfieran entre ellos. En el apartado 2.8.4 se tratara este tema con 
mas detalle. 



2.6.2. Control de la visibilidad de un simbolo 

Por defecto todos los sfmbolos de una librerfa se exportan (son publicos), es 
decir, son accesibles desde los clientes de la librerfa. En general, conviene 
exportar solo los sfmbolos de interfaz que va a usar el usuario, no 
necesariamente todos los sfmbolos que definimos durante la programacion de 
la librerfa. Esto se debe a que cuantos mas sfmbolos exportados haya, mas 
sfmbolos tiene que cargar el cargador dinamico al cargar la librerfa. 

En Mac OS X existen varias formas de controlar la visibilidad de los sfmbolos. 
En los siguientes subapartados vamos a comentar con detalle cada una de 
ellas. 

1. Usar el modificador static 

La primera forma de evitar que se exporte una variable o funcion global es 
usar el modificador static. Los sfmbolos marcados con static no son 
exportados. El Listado 3.5 muestra un ejemplo de como podemos 
implementar una librerfa donde los sfmbolos setNombre y GetNombre son 
exportados, pero los sfmbolos Nombre y setNombre no. 



/* usuario. c */ 

#include <string.h> 

static char Nombre [255] = ""; 

static int _SetNombre ( const char* n) 
{ 

strcpy (Nombre, n) ; 
return 0; 

} 
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/ / Funcion wrapper 

int SetNombre (const char* n) 

{ 

if ( n ! =NULL && strlen (n) <255 ) 

return _SetNombre (n) ; 
else 

return 1; // Parametro no valido 



const char* GetNombreO 
{ 

return Nombre; 



Listado 3.5: Ocultacion de sfmbolos con static 



Si ahora compilamos esta librerfa: 



$ gcc -dynamic lib usuario.c -o libUsuario . dylib 



Podemos usar el comando nm para ver los sfmbolos de la librerfa: 

$ nm libUsuario . dylib 

libUsuario . dylib (dylibl . o) : 

00000el8 t initialize_Cplusplus 

00000df8 t dyld_func_lookup 

u mh_dylib_header 

OOOOOdfO t cfm_stub_binding_helper 

00001000 d dyld mh_dylib_header 

00001108 s dyld_f unc_lookup_pointer 

00001104 s dyld_lazy_symbol_binding_entry_point 

OOOOOdcO t dyld_stub_binding_helper 



libUsuario . dylib (ccLGTGxY . o) : 
00000 f4c T _GetNombre 
00001004 d _Nombre 
OOOOOedc T _SetNombre 
00000e90 t SetNombre 

U _strcpy 

U _strlen 

u dyld_stub_binding_helper 



El comando muestra tanto los sfmbolos exportados como los no exportados. 
La Tabla 3.2 muestra los tipos de sfmbolos que puede identificar nm en un 
fichero de codigo objeto. Los sfmbolos que aparecen en mayusculas son 
sfmbolos exportados, y los que aparecen en minusculas son sfmbolos privados 
(o no exportados). 

En caso de que solo nos interesen los sfmbolos publicos podemos usar la 
opcion -g: 
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$ nm -g libUsuario . dylib 

libUsuario . dylib (dylibl . o) : 

libUsuario . dylib ( ccsNU7NW . o) : 
00000f4c T _GetNombre 
OOOOOedc T _SetNombre 

U _strcpy 

U strlen 



Observese que sfmbolos como _strcpy o strien aparecen como publicos, 
esto se debe a que estos sfmbolos han sido cogidos de una librerfa de enlace 
estatico donde eran sfmbolos publicos. 



Tipo 


Description 


u 


Sfmbolo externo indefinido (Undefined), es decir, un sfmbolo que ha 
sido declarado pero no definido por los modulos objeto. 


T 


Seccion de codigo (Text). 


D 


Seccion de datos (Data). 


B 


Seccion BSS. 


C 


Sfmbolo comun. Vease apartado 2.11.2 


I 


Sfmbolo indirecto. 


S 


Sfmbolo en otra seccion distinta a las anteriores. 




Sfmbolo de depuracion. Para que se muestren debemos usar -a 



Tabla 3.2: Tipos de sfmbolos de acuerdo al comando nm 



El inconveniente que a veces presenta el uso del modificador static es que 
ocultamos las funciones marcadas con static, como por ejemplo 
setNombre, a otros modulos de nuestra librerfa. Esto hace que el uso del 
modificador static no sea adecuado cuando queremos ocultar un sfmbolo a 
los clientes de la librerfa, pero permitir que sea accesible desde todos los 
modulos de nuestra librerfa. 

2. Uso de listas de exportacion 

Un segunda opcion es indicar en un fichero los unicos sfmbolos que queremos 
exportar (incluido el prefijo "_" ya que son sfmbolos destinados a ser usados 
por el enlazador, no al compilador). 

Para ello empezamos creando un fichero con los sfmbolos a exportar como el 
siguiente: 

$ cat usuario . export 

_SetNombre 
_GetNombre 

Y compilamos la librerfa con la opcion -exported symbois iist, la cual 
sirve para indicar este fichero: 



Pag 60 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 

$ gcc usuario.c -dynamiclib -exported_synibols_list 
usuario . export -o libUsuario . dylib 

3. Indicar la visibilidad con atributos 

Esta es posiblemente la forma mas recomendable para indicar la visibilidad de 
los sfmbolos de la librerfa. Consiste en usar el atributo visibility (vease la 
Tabla 2.4 y Tabla 2.5 del Tema 2). Este atributo puede tomar uno de los 
valores que aparecen en la Tabla 3.3. 



Visibilidad 


Description 


default 


Visibilidad por defecto, que es publica. 


hidden 


El sfmbolo no debe de ser exportado en una librerfa de 
enlace dinamico. 


internal 


Igual que la anterior, pero con el anadido de que el sfmbolo 
tampoco va a ser llamado desde otro modulo de la librerfa. 
Esto permite al compilador no generar el registro PIC para 
el sfmbolo. 



Tabla 3.3: Niveles de visibilidad de un sfmbolo para el atributo visibility 



Normalmente los unicos valores que vamos a usar son default, para 
exportar el sfmbolo, y hidden para ocultar el sfmbolo. En concreto, default 
se lo pondremos a los sfmbolos a exportar, y hidden no lo vamos a poner en 
los sfmbolos a ocultar, sino que en su lugar usaremos la opcion - 
fvisibiiity=hidden que oculta todos los sfmbolos que no tengan puesto el 
atributo de visibilidad. El Listado 3.6 muestra como implementar la librerfa 
libusuario. dyiib usando esta tecnica. Hemos usado el identificador del 
preprocesador export para marcar como exportables solo a los sfmbolos que 
nos interesa. Ademas, ahora los sfmbolos que no queremos exportar no los 
hemos marcado como static. 

Para compilarlo podemos usar el comando: 

$ gcc -dynamiclib -fvisibility=hidden usuario.c -o 
libUsuario . dylib 



/* usuario.c */ 
#include <string.h> 

#define EXPORT attribute ( (visibility ( "default" )) ) 

char Nombre[2 55] = ""; 

int _SetNombre (const char* n) 
{ 

strcpy (Nombre, n) ; 
return 0; 

J 
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EXPORT int SetNombre ( const char* n) 
{ 

if ( n ! =NULL && strlen (n) <255 ) 

return _SetNombre (n) ; 
else 

return 1; // Parametro no valido 

} 

EXPORT const char* GetNombreO 
{ 

return Nombre; 
} 

Listado 3.6: Indicar la exportabilidad de los sfmbolos con atributos 



2.7. Inicializacion de una librena 

Cuando se carga una librena de enlace dinamico, esta puede necesitar 
preparar recursos o realizar tareas de inicializacion antes de hacer cualquier 
otra cosa. Estas tareas son realizadas por las llamadas funciones de 
inicialicacion de librena y funciones de finalizacion de librena. 

Tradicionalmente estas tareas han sido realizadas por las funciones init o 
y _f ini ( ) . Mac OS X tiene otra forma de implementar estas funciones que es 
la que vamos a comentar ahora. 

Las aplicaciones tambien pueden definir sus propias funciones de inicializacion 
y finalizacion, aunque en este apartado nos vamos a centrar en ver como se 
crean estas funciones para las librerfas de enlace dinamico. 

Para indicar que una funcion es de inicializacion/finalizacion se usan los 
atributos constructor y destructor respectivamente. Es recomendable que 
estas funciones no esten exportadas, para lo cual es buena idea el marcarlas 

COn el atributO visibility="hidden" 1 . 

Si una librena tiene varias funciones de inicializacion, estas se ejecutan en el 
orden en que las encuentra el compilador. Por contra las funciones de 
finalizacion se ejecutan en el orden inverso a el que las encuentra el 
compilador. 



1 En gcc existe tambien la opcion -init nombrefn que recibe el nombre de una funcion sin 
parametros y sin retorno, y la ejecuta como funcion de inicializacion de librena (es decir, la 
marca como constructor). Pero en este caso solo podemos dar una funcion de inicializacion 
de liberia. Ademas, no existe la correspondiente opcion de gcc para indicar una funcion de 
finalizacion de librena. 
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Como ejemplo de creacion y uso de estas funciones vamos a crear una 
librerfa con varias funciones de inicizalizacion/finalizacion como muestra el 
Listado 3.7. 



/* inicializable . c */ 
#include <stdio.h> 

#define INIT attribute (( constructor , visibility ( "hidden" )) ) 

#define FINI attribute ( (destructor, visibility ( "hidden" )) ) 

INIT void Inicializadorl ( ) 
printf (" [%s] %s\n", FILE , tunc ) ; 

INIT void Inicializador2 ( ) 
printf (" [%s] %s\n", FILE , func ) ; 

FINI void Finalizadorl ( ) 
printf (" [%s] %s\n", FILE , func ) ; 

FINI void Finalizador2 ( ) 
printf (" [%s] %s\n", FILE , func ) ; 



Listado 3.7: Ejemplo de funciones de inicializacion/finalizacion de librerfa 
Ahora podemos generar la librerfa con el comando: 

$ gcc inicializable . c -dynamic lib -o liblnicializable . dylib 



/* trial. c */ 

#include <stdio.h> 

int main ( ) 
{ 

printf (" [%s] %s\n", FILE , func ) ; 

return 0; 



Listado 3.8: Programa que usa la librerfa con inicializadores/finalizadores 
Y enlazar el programa del Listado 3.8 con el comando: 

$ gcc trial . c liblnicializable . dylib -o trial 
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Y a I ejecutarlo obtenemos: 



$ . /trial 

[inicializable.c] 
[inicializable.c] 
[trial. c] main 
[inicializable.c] 
[inicializable.c] 



Inicializadorl 
Inicializador2 

Finalizador2 
Finalizadorl 



Es importante tener en cuenta que las funciones de inicializacion/finalizacion 
de una librerfa siempre pueden llamar a funciones de otra librerfa. Esto se 
debe a que el cargador dinamico siempre ejecuta las funciones de 
inicializacion/finalizacion de las librerfas de que se depende antes de ejecutar 
las funciones de inicializacion/finalizacion de nuestra librerfa. 

Por ultimo, comentar que a partir de Mac OS X 10.4 las funciones de 
inicializacion pueden acceder a los argumentos de la Ifnea de comandos y a 
las variables de entorno igual que lo hace la funcion maino : recibiendolos 
como parametros. El Listado 3.9 muestra como se implementarfa una funcion 
de este tipo. 



INIT void Inicializadorl (int argc, char* argv [ ] , char* envp [ ] ) 
{ 

printf (" [%s] %s\n", FILE , func ) ; 

} 

Listado 3.9: Funcion de inicializacion que lee los argumentos y variables de entorno 



2.8. Encontrar simbolos importados 

Cuando en el programa cliente el cargador dinamico carga un fichero de 
librerfa, este tiene que conectar los sfmbolos importados por el programa 
cliente, con los sfmbolos exportados por la librerfa. En este apartado 
detallaremos como ser realiza este enlace. 

2.8.1. Enlazar simbolos 

El enlace de simbolos (symbols binding), tambien llamado resolucion de 

simbolos, es el proceso por el que las referencias que hace una imagen 
(ejecutable o librerfa de enlace dinamico) a datos y funciones de otras 
imagenes son inicializadas para apuntar al sfmbolo que las corresponde. 

Cuando una aplicacion se carga, el cargador dinamico mapea las librerfas de 
enlace dinamico que usa la aplicacion en la memoria del proceso, pero no 
resuelve las referencias, sino que estas suelen usar enlace tardio (lazy 
binding), que consiste en que las referencias no se resuelven hasta que se 
usan por primera vez. Logicamente este enlace se realiza de forma recursiva, 
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es decir si una librerfa usa a su vez otra librerfa, esta segunda librerfa tambien 
se tiene que mapear en memoria. 

Tengase en cuenta que mientras que mapear un fichero en memoria (p.e. 
usando la funcion mmap ( ) ) es poco costoso, ya que el fichero no se carga 
realmente en memoria hasta que se produce un fallo de pagina, enlazar todos 
los sfmbolos de una librerfa implica recorrer todas las direcciones de memoria 
de la aplicacion que hacen referenda a sfmbolos externos asignandolas la 
direccion de memoria donde esta cargado el sfmbolo. Para evitar el coste de 
enlazar todos los sfmbolos de una librerfa (muchos de los cuales posiblemente 
luego no sean usados) se suele usar enlace tardfo. 

De hecho, el cargador dinamico puede enlazar sfmbolos de varias formas 
dependiendo de la opcion que pasemos, o bien al comando id cuando 
enlazamos una aplicacion con una librerfa de enlace dinamico, o bien al 
comando libtooi cuando le pedimos enlazar una librerfa de enlace dinamico 
con otra librerfa de enlace dinamico: 

• Por defecto se usa el enlace tardio (tambien llamado lazy binding o 
just-in-time binding), donde el cargador dinamico enlaza un sfmbolo 
solo la primera vez que se va a utilizar el sfmbolo. En este modo, si un 
sfmbolo nunca se utiliza, nunca se enlaza. 

• Otra forma de enlazar los sfmbolos es el enlace adelantado (tambien 
llamado load-time binding), donde los sfmbolos de una librerfa son 
resueltos cuando el cargador dinamico mapea la librerfa durante el 
arranque del programa. En este caso debemos pasar a id durante el 
enlazado de la aplicacion (o a libtooi durante el enlazado del fichero 
librerfa) la opcion -bind at ioad. Esta opcion resulta util, por 
ejemplo, en las aplicaciones en tiempo real donde la resolucion de 
sfmbolos puede hacer que la aplicacion sufra latencias intolerables. 

• El preenlazado (prebinding) es una forma de enlace adelantado que 
realiza el enlazado de sfmbolos en tiempo de compilacion para evitar 
hacerlo en tiempo de ejecucion. En el siguiente apartado se describe 
con mas detalle esta tecnica. 

• Referencias weak. Este tipo de referencias fueron introducidas en 
Mac OS X 10.2, y son utiles para acceder a caracterfsticas que no estan 
disponibles en versiones antiguas del sistema operativo, pero sf en 
nuevas versiones. En el apartado 2.8.3 detallaremos como se usan 
este tipo de referencias. 
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2.8.2. Preenlazado 

En principio el enlace de sfmbolos se tiene que hacer en tiempo de ejecucion 
porque, hasta que la librerfa no se carga, no se conoce las zonas de memoria 
que estan libres en el proceso, es decir, las zonas de memoria que estan 
libres en el espacio de memoria de la aplicacion. Las librerfas del sistema 
operativo son librerfas muy usadas por muchas aplicaciones, con lo que una 
posible optimizacion consiste en pedir al cargador dinamico que, si es posible, 
las mapee siempre en determinada region de memoria del proceso. 
Logicamente, si parte de esta region esta ya ocupada por otra librerfa el 
preenlazado no es posible. En caso de que esta region no este ocupada, la 
librerfa se cargara en esa direccion y las referencias de la aplicacion que 
hagan referenda a los sfmbolos de la librerfa no necesitarfan ser enlazadas, lo 
cual supone una considerable mejora del rendimiento. En caso de que el 
cargador dinamico no pueda cargar la librerfa en la direccion de memoria 
preasignada, el cargador dinamico debera a continuacion modificar todas las 
referencias de la aplicacion que hacen referenda a los sfmbolos de la librerfa 
para que el enlace sea correcto. 

El preenlazado requiere que las librerfas especifiquen su direccion de memoria 
base preferida, y que estas regiones no solapen. Apple no recomienda crear 
este tipo de librerfas a los desarrolladores externos a Apple, ya que sino se 
vuelve muy diffcil conseguir que no haya solape entre las librerfas, pero las 
librerfas del sistema operativo sf suelen estar creadas con esta opcion, y las 
aplicaciones pueden pedir usar las ventaja del preenlazado con la opcion - 

prebind de Id. 

Podemos ver si un ejecutable esta preenlazado con alguna librerfa con el 
comando otooi y la opcion -h (que muestra las cabeceras de Mach-0 del 
fichero) y la opcion -v. Por ejemplo, para ver el tipo de enlace de sfmbolos 
que utiliza iMovie podemos ejecutar el comando: 

$ otool -h -v /Applications/iMovie . app/Contents/MacOS/ iMovie 

Mach header 

magic cputype filetype flags 

MH_MAGIC PPC EXECUTE NOUNDEFS DYLDLINK PREBOUND TWOLEVEL 

Entre los flags de la cabecera Mach-0 encontramos el flag prebound, que 
indica que se esta usando preenlazado. 

Podemos consultar la direccion preferida de carga de una librerfa con el 
comando otooi y la opcion -1, que muestra los comandos del cargador 
dinamico. Por ejemplo, para ver la direccion preferida de carga de la librerfa 

/usr/iib/iibz .dyiib usamos el comando: 



Pag 66 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 



$ otool -1 /usr/lib/libz .dylib 

libz . dylib : 
Load command 0 

cmd LC_SEGMENT 
cmdsize 3 96 

segname TEXT 

vmaddr 0x9108e000 
vmsize OxOOOOfOOO 
fileoff 0 
filesize 61440 

maxprot 0x00000007 
initprot 0x00000005 
nsects 5 
flags 0x0 

Donde vmaddr nos muestra la direccion preferida de carga, y vmsize nos 
indica el tamano del segmento text de la librerfa. 



2.8.3. Simbolos weak 

Existen dos tipos de simbolos weak: Las referencias weak y definiciones 
weak. En este apartado veremos que son y para que sirve cada tipo. 

Referencias y definiciones weak 

Las referencias weak 1 son simbolos externos que importa una aplicacion 
donde, a diferencia de los demas tipos de simbolos externos, si el cargador 
dinamico no encuentra el sfmbolo lo deja a null en vez de fallar. Antes de 
que una aplicacion use estos simbolos, debe comprobar que el sfmbolo no sea 
nulo de la forma: 



(FuncionWeak ! =NULL) 



Para que una aplicacion indique que una funcion debe ser tratada como una 
referenda weak, debe poner el atributo weak import en el prototipo de la 
funcion de la forma: 



Tengase en cuenta que tiene que ser la aplicacion, y no la librerfa de enlace 
dinamico, la que declare a un sfmbolo que va a importar como referenda 
weak 2 . 



1 Si esta familiarizado con el formato de los ejecutables ELF puede pensar que una referenda 
weak es un sfmbolo weak de ELF, no los confunda, no es lo mismo. Los simbolos weak de 
ELF son simbolos que pueden ser sobreescritos por simbolos no weak. El equivalente a los 
simbolos weak de ELF en Mac OS X son las definiciones weak. 

2 Razon por la que se dio el nombre weak import al atributo. 
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Podemos hacer que todos los sfmbolos de una libreria a importar sean 
tratados como referencias weak usando la opcion -weak iibrary 1 libreria 
de id. Esto permite que al ejecutar el programa no falle si no existe esta 
libreria de enlace dinamico, pero el programa debe de comprobar que los 
sfmbolos no sean null antes de usar cualquier sfmbolo de la libreria asf 
importada. 

Las definiciones weak son sfmbolos que son ignorados por el enlazador si 
existe otra definicion no weak del sfmbolo. Para declarar un sfmbolo como 
definicion weak se usa el atributo weak de la siguiente forma: 



Esto permite que, por ejemplo, una aplicacion redefina, en la imagen de la 
aplicacion, una funcion, y solo si la aplicacion no implementa esta funcion se 
usa la definicion weak de una librerfa. 



Este tipo de sfmbolos los usan los compiladores de C++ para implementar la 
instanciacion de plantillas. El compilador de C++ a las instanciaciones 
implfcitas de plantillas las marca como definiciones weak, y a las 
instanciaciones explfcitas las marca como definiciones normales (no weak). 
De esta forma el enlazador estatico siempre elige una instanciacion explfcita 
frente a una implfcita. 



Ejemplo de referencias weak 



El Listado 3.10 muestra un programa que usa la librerfa del Listado 3.6. 



/* usausuario.c */ 



#include <stdio.h> 



int SetNombre (const char* n) ; 
const char* GetNombre () ; 



int main ( ) 
{ 

SetNombre ("Fernando") ; 

printf("El nombre es %s\n" , GetNombre ()) ; 
return 0; 



Listado 3.10: Programa que usa la librerfa libusuario.dyiib 



Podemos compilarlo y ejecutarlo asf: 



$ gcc usausuario.c libUsuario . dylib -o usausuario 



1 En caso de tratarse de un framework, en vez de una librerfa de enlace dinamico, se usa la 

Opcion -weak_f ramework libreria. 
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$ . /usausuario 

El nombre es Fernando 

Si ahora borrasemos el fichero libUsuario . dylib e intentaramos ejecutar 
de nuevo el programa: 

$ rm libUsuario . dylib 
$ . /usausuario 

dyld: Library not loaded: libUsuario . dylib 

Referenced from: ./usausuario 

Reason: image not found 
Trace/BPT trap 

El cargador dinamico falla porque no encuentra la librerfa de enlace dinamico. 

Para poder detectar la ausencia de la librerfa no necesitamos modificar el 
fichero del Listado 3.6, lo que necesitamos es modificar el fichero 
usausuario. c para indicarle que enlace como referencias weak los sfmbolos 
de la librerfa de enlace dinamico a importar. El Listado 3.11 muestra como 
quedarfa ahora el fichero usausuario . c. 



/* usausuario. c */ 
#include <stdio.h> 

#define WEAK_IMPORT attribute ( (weak__import) ) 

WEAK_IMPORT int SetNombre (const char* n) ; 
WEAK_IMPORT const char* GetNombre () ; 

int main ( ) 
{ 

if (SetNombre && GetNombre) 
{ 

SetNombre ("Fernando") ; 

printf("El nombre es %s\n" , GetNombre ()) ; 

} 

else 

printf ( "Falta la libreria con las funciones weak\n"); 
return 0; 

} 

Listado 3.11: Programa que enlace los sfmbolos de una librerfa como referencias weak 

Ahora compilamos el Listado 3.11 y obtenemos: 

$ gcc usausuario. c libUsuario . dylib -o usausuario 

/usr/bin/ld: warning weak symbol references not set in output 
with MACOSX_DEPLOYMENT_TARGET environment variable set to: 
10.1 

/usr/bin/ld: warning weak referenced symbols: 
_GetNombre 
SetNombre 
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/usr/bin/ld : warning dynamic shared library: libUsuario . dylib 
not made a weak library in output with 

MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 

Los warning avisan de que la variable de entorno macosx_deployment_ 
target no esta fijada, y cuando no se fija se asume como plataforma destino 
del ejecutable Mac OS X 10.1. Por desgracia las referencias weak aparecieron 
en Mac OS X 10.2 con lo que el compilador no enlaza con los sfmbolos como 
referencias weak. 

Podemos solucionar el problema fijando la variable de entorno 

macosx_deployment_target y volviendo a compilar: 

$ export MACOSX_DEPLOYMENT_TARGET=10 .2 

$ gcc usausuario.c libUsuario. dylib -o usausuario 

Ahora el programa ejecuta correctamente: 

$ . /usausuario 

El nombre es Fernando 

Y si borramos la librerfa, ahora dyid detecta que el sfmbolo weak no se 
puede cargar, lo pone a null, y la aplicacion no falla. 

$ rm libUsuario . dylib 
$ . /usausuario 

Falta la libreria con las funciones weak 

Puede usar el comando nm con la opcion -m para ver que sfmbolos estan 
siendo importados como weak: 

$ nm -m usausuario | grep weak 

(undefined) weak external _GetNombre (from libUsuario) 
(undefined) weak external _SetNombre (from libUsuario) 

En la cabecera del fichero de la aplicacion se definen una serie de comandos 
de carga (load commands), que son comandos que se ejecutan al cargar la 
aplicacion, y que por ejemplo ejecutan dyid para cargar librerfa. Podemos ver 
estos comandos de carga ejecutando otooi con la opcion -i. 

Observese que basta con que un sfmbolo ( GetNombre o setNombre) de la 
librerfa de enlace dinamico a usar no este declarado como referenda weak 
para que dyid falle al ir a cargar la librerfa. Por ello existe la regla de que si 
una aplicacion importa todos los sfmbolos de una librerfa de enlace dinamico 
como referencias weak, el comando de carga de la librerfa es weak (de tipo 
lc load weak dylib). Basta con que un solo sfmbolo de la librerfa de 
enlace dinamico no sea importado como weak para que el comando de carga 
no sea weak. Por ejemplo si ejecutamos: 
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$ otool -1 usausuario 



Load command 5 

cmd L C_LOAD_WE AK_D Y L I B 
cmdsize 4 4 

name libUsuario . dylib (offset 24) 
time stamp 1136411437 Wed Jan 4 22:50:37 2006 
current version 0.0.0 
compatibility version 0.0.0 



Vemos que nos informa que el comando de carga de libusuario.dyiib es 

de tipO LC_LOAD_WE AK_DYL I B . 

Si quitamos el prefijo weak import a alguna de las funciones del Listado 3.11 
el comando otool nos devolvera ahora que no esta cargandose la librerfa 
como weak. 

$ otool -1 usausuario 



Load command 5 

cmd LC_LOAD_DYLIB 
cmdsize 4 4 

name libUsuario . dylib (offset 24) 
time stamp 1136411629 Wed Jan 4 22:53:49 2006 
current version 0.0.0 
compatibility version 0.0.0 



Macros para control de compatibilidad 

El fichero de cabecera /usr/inciude/AvaiiabiiityMacros .h contiene una 
serie de macros que nos ayudan a controlar la compatibilidad de una 
aplicacion a la hora de ejecutarla en distintas versiones de Mac OS X. Es 
decir, cuando una aplicacion, compilada en una version de sistema operativo 
mas moderna, se ejecuta en una version antigua de sistema operativo, 
podrfan no estar disponibles librerfas de enlace dinamico que solo existen en 
la version moderna. Entonces vamos a describir que macros nos permiten 
saber si nuestro programa se esta ejecutando en una version antigua del SO. 

Podemos fijar el macro mac os x version min required a una version de 
sistema operativo, y de esta forma indicar la version minima de sistema 
operativo que nuestra aplicacion requiere para ejecutar. En caso de que no 
este definido este macro, pero si macosx deployment target, este serfa el 
valor que cogerfa, sino por defecto vale 1010 1 . Todas las APIs por debajo o 



1 Observese que macosx_deployment_target recibe valores de la forma 10.1 
mientras que mac_OS_x_version_min_required recibe valores de la forma 1010, 
que es lo que vale el identificador mac_OS_x_version_10_1 que encontramos en el 
fichero de cabecera. El sistema de macros se encarga de realizar las transformaciones 
oportunas. 
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iguales a esta version seran enlazadas como referencias normales (no weak). 
Las APIs definidas despues de la version indicada en mac_os_x_version_ 
min required, seran enlazadas como referencias weak. 

A este macro le podemos asignar valores, por ejemplo, con la opcion -d de la 
forma: 

- DMAC_0 S_X_VE RS I ON_M I N_RE QU I RE D=MAC_0 S_X_VE RS I ON_l 0_X 

Donde x es la version de sistema operativo de que se trate. 

Por otro lado, el macro mac_os_x_version_max_allowed permite especificar 
el numero maximo de version de las APIs del sistema operativo que nuestra 
aplicacion puede usar. Las APIs que sean superiores a esta version no seran 
visibles durante la compilacion de nuestra aplicacion. En caso de que este 
macro no se defina estara fijado a la mayor version actual de nuestro sistema 
operativo, es decir, la mas alta que soporte nuestro compilador. En el 
momento de escribir este tutorial esta serfa la 10.4. 

Un uso comun de estas macros consiste en definir el valor de mac os x 
_version_min_allowed al mismo valor que mac_os_x_version_max_ 
allowed, y los errores que se produzcan no indican APIs que no estan 
definidas para esa version. Por ejemplo, primero los fijamos a 
mac os x version io i y si se producen errores sabemos que nuestro 
software requiere una version mas moderna del sistema operativo, luego 
podemos probar a fijarlos a por ejemplo mac_os_x_version_io_2. 

2.8.4. Nombres en dos niveles 

Para referirnos a un sfmbolo de una librerfa de enlace dinamico normalmente 
damos un nombre de sfmbolo. Este nombre se suele dar siguiendo el 
convenio C, con lo que la funcion setNombre tendra el sfmbolo setNombre. 

Las aplicaciones creadas con las herramientas de desarrollo de Mac OS X 10.0 
cargaban todos los sfmbolos de todas las librerfas de enlace dinamico usando 
una sola lista global de sfmbolos. Cualquier sfmbolo al que la aplicacion se 
referfa podfa ser encontrado en cualquier librerfa de enlace dinamico, con la 
unica restriccion de que la librerfa formase parte de la lista de librerfas de las 
que dependfa la aplicacion (o una de las librerfas de las que dependa otra 
librerfa). 

Mac OS X 10.1 introdujo los nombres de sfmbolos en dos niveles. El primer 
nivel da el nombre de la librerfa que contiene el sfmbolo, y el segundo es el 
nombre del sfmbolo. Es decir, cuando se usan nombres en dos niveles, el 
enlazador estatico, al guardar referencias a los sfmbolos importados, lo que 
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hace es guardar referencias tanto al nombre de la librerfa que contiene el 
sfmbolo, como al nombre del sfmbolo. 

Los nombres en dos niveles presentan dos ventajas respecto a los nombres 
en un nivel: 

• La primera ventaja es que mejoran el rendimiento ya que se acelera el 
proceso de busqueda de sfmbolos en librerfas. Esto se debe a que con 
los nombres en dos niveles el cargador dinamico sabe exactamente en 
que librerfa buscar el sfmbolo. Por contra, usando nombres en un nivel 
el cargador dinamico debe de buscar por todas las librerfas, a ver cual 
de ellas contiene el sfmbolo. 

• La segunda ventaja es que mejoran la compatibilidad hacia adelante. 
En el esquema de nombres en un nivel, dos o mas librerfas (que use 
una misma aplicacion) no pueden tener sfmbolos con el mismo nombre 
ya que sino el enlazador estatico producira un error de enlazado. Sin 
embargo, si mas adelante una librerfa incorpora un sfmbolo que ya 
existfa en otra librerfa con la que enlazaba la aplicacion, el cargador 
dinamico podrfa enlazar equivocadamente con otra librerfa. 

Por defecto, a partir de Mac OS X 10.1 se usan nombres en dos niveles. Si por 
alguna razon desea usar nombres en un nivel debe pasar la opcion - 

f lat_namespace al COITiandO Id. 

2.9. Librerfas C++ 

El hecho de que C++ use name mangling para representar los sfmbolos tiene 
una serie de implicaciones que debemos tener en cuenta a la hora de 
desarrollar una librerfa C++, y que vamos a estudiar en este apartado. 

Aunque tanto las funciones como las clases C++ puede exportarse, Apple 
recomienda seguir las siguientes dos reglas a la hora de crear una librerfa de 
enlace dinamico C++: 

1. La clase debe exportar tanto los constructores publicos como los 
metodos publicos. 

2. Las funciones, siempre que sea posible, deben exportarse al estilo C 

(USandO export "C")- 

3. Las clases deben declarar todos los metodos publicos virtuales, y crear 
funciones factory para instanciar los objetos. 
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La segunda regla se propuso para poder acceder a las funciones de librerfas 
cargadas dinamicamente con las funciones de la familia diopeno. 
Recuerdese que en estas funciones nosotros pasabamos a disymo la cadena 
" nu e va p e r s on a " ydisym() buscaba en la librerfa la cadena 
" NuevaPersona" . Al tener las funciones C++ una tecnica de name mangling 
que no se garantiza que se conserve en el futuro, las funciones C no deberfan 
de confiar en componer el nombre de la funcion con name mangling (p.e. 

z4sumaii). El exportar, siempre que no exista sobrecarga, los nombres de 

las funciones al estilo C evita posibles problemas de compatibilidad hacia 
adelante. 

La razon de la tercera regla es que si los metodos publicos (los que va a 
llamar la aplicacion) son virtuales pueden ejecutarse sin necesidad de conocer 
el nombre del sfmbolo en la librerfa, aunque eso si, solo a traves de punteros, 
que es cuando el enlace dinamico actua. 

La primera regla se pone para poder acceder a la librerfa desde C++, ya que 
cuando un objeto de la librerfa es instanciado en la pila o como objeto global, 
la llamada a los metodos serfa estatica (y deberan de estar exportados). 



El Listado 3.12 muestra un ejemplo de como deberfa de declararse el 
prototipo de una clase, y el Listado 3.13 muestra como deberfa de 
implementarse los metodos de la clase. 



/* CPersona.h */ 




#ifndef CPERSONA H 
#define CPERSONA H 




class CPersona 




{ 

private : 

char nombre [100] ; 
public : 

CPersona ( const char* nombre); 

virtual void setNombre ( const char* nombre); 

virtual const char* getNombre() const; 

}; 




extern "C" CPersona* NuevaPersona ( const char* nombre); 
extern "C" void BorraPersona (CPersona* p) ; 





Listado 3.12: Prototipo de una librerfa de enlace dinamico C++ 
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/* CPersona.cpp */ 
#include "CPersona.h" 

#define EXPORT attribute ( (visibility ( "default" )) ) 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
EXPORT CPersona* NuevaPersona (const char* nombre) 

return new CPersona (nombre) ; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
EXPORT void BorraPersona ( CPersona* p) 

delete p; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
EXPORT CPersona :: CPersona ( const char* nombre) 

strcpy (this->nombre, nombre) ; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
EXPORT void CPersona :: setNombre ( const char* nombre) 

strcpy (this->nombre, nombre) ; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
const char* CPersona :: getNombre ( ) const 

return this->nombre ; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
Listado 3.13: Implementacion de una libreria de enlace dinamico C++ 

Podemos generar la libreria con el comando: 

$ g++ -fvisibility=hidden CPersona.cpp -dynamic lib -o 
libPersona . dylib 

Logicamente, cuando la libreria de enlace dinamico es una libreria 
dependiente de la aplicacion (cargada por dyid) se pueden usar los 
operadores new y delete para crear objetos, o bien crear instancias globales 
o locales de los objetos. Por contra, cuando estemos enlazando con la libreria 
en tiempo de ejecucion desde las funciones de la familia diopeno 
necesitamos usar las funciones factory que hemos declarado como extern 
"C" para que resulte mas sencillo encontrar su sfmbolo. 

El Listado 3.14 muestra como podemos usar los objetos de la libreria de 
enlace dinamico accediendo desde las funciones de la familia diopen o . 
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/* usapersona */ 

#include "CPersona.h" 

using namespace std; 

int main ( ) 
{ 

/ / Abre la libreria 

void* lib = dlopen (" . /libPersona . dylib" , 0) ; 
if ("lib) 
{ 

cerr << "Fallo abriendo la libreria" << endl; 
return 1; 

} 

// Crea un objeto 

CPersona* ( *pf nl ) (const char*) = 

(typeof (pfnl) ) dlsym(lib, "NuevaPersona" ) ; 

if (pfnl==NULL) 
{ 

cerr << "Fallo accediendo a NuevaPersona () " << endl; 
return 1; 

} 

CPersona* p = pf nl ( "Fernandito" ) ; 
// Usa el objeto 
p->setNombre ( "Don Fernando") ; 
cout << p->getNombre ( ) << endl; 
// Libera el objeto 
void(*pfn2) (CPersona* p) = 

(typeof (pfn2) ) dlsym(lib, "BorraPersona" ) ; 

if (!pfn2) 
{ 

cerr << "Fallo accediendo a BorraPersona () " << endl; 
return 1; 

} 

pfn2 (p) ; 

/ / Cierra la libreria 
dlclose (lib) ; 
if (!lib) 
{ 

cerr << "Fallo cerrando la libreria" << endl; 
return 1; 

} 

return 0; 

J 

Listado 3.14: Uso de objetos de libreria de enlace dinamico con diopen o 

Ahora podnamos compilar y ejecutar este programa con: 

$ g++ usapersona . cpp -o usapersona 
$ . /usapersona 
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2.10.C6digo dinamico 

Para poder disponer de librerfas de enlace dinamico, las aplicaciones, las 
herramientas de desarrollo, las librerfas de enlace dinamico, y el cargador 
dinamico deben dar soporte para dos tecnologfas: Position Independent Code 
(PIC) y direccionamiento indirecto. En este apartado se describen estas dos 
tecnologfas. 

2.10.1. Position Independent Code 

Como se introdujo en el apartado 2.3, PIC es el nombre que recibe la tecnica 
que permite al cargador dinamico cargar el codigo de una librerfa de enlace 
dinamico en una region no fija de memoria. Si el codigo generado no es PIC, 
el cargador dinamico necesitarfa cargar el codigo de la librerfa de enlace 
dinamico siempre en la misma direccion de memoria. Esto serfa asf con el fin 
de que las referencias relativas a variables de la librerfa (situadas 

normalmente en el segmento data) que haga el codigo de la librerfa 

(situado normalmente en el segmento text) sean direccionamientos 

correctos. Logicamente, esta limitacion harfa el mantenimiento de las librerfas 
de enlace dinamico instaladas en el sistema operativo extremadamente diffcil. 

Mach-O, el formato de los binarios de Mac OS X, por defecto es PIC, y se 

basa en la observacion de que el segmento data se encuentra siempre a 

un offset constante del segmento text. Es decir, el cargador dinamico, 

cuando carga una librerfa siempre carga el segmento text a la misma 

distancia del segmento data. De esta forma una funcion puede sumar a su 

direccion un offset fijo para determinar la direccion del dato al que quiere 
acceder. Esta forma de direccionamiento, llamada direccionamiento relativo, 
actualmente esta implementado en el ensamblador tanto de PowerPC como 
de Intel con lo que un direccionamiento con codigo PIC no es mas lento que 
su correspondiente direccionamiento con codigo no PIC. De hecho, todos los 

segmentos del formato Mach-O, y no solo los segmentos text y data, 

se cargan a distancias fijas de los demas segmentos 1 . 

El codigo PIC es requerido solo por las librerfas de enlace dinamico, no por las 
aplicaciones, que normalmente siempre se cargan en la misma direccion de 
memoria virtual. Aunque el codigo PIC no es mas lento, en cuanto a lo que a 
direccionamientos se refiere, si que introduce restricciones que aumentan el 
tamano del codigo generado y reducen su rendimiento. Aunque las 



1 Si esta familiarizado con el formato ELF (Executable and Linking Format), muy utilizado por 
sistemas como Linux, observe que Mach-O no tiene una GOT (Global Offset Table) ya que en 
el formato Mach-O no se consulta esta tabla para acceder a otros segmentos, sino que se 
utilizan direcciones relativas, lo cual es mas rapido debido a que el direccionamiento se hace 
directamente usando instrucciones maquina de direccionamiento relativo. El formato ELF se 
diseno cuando no todas las maquinas soportaban (ni siguen soportando) direccionamiento 
relativo. 
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aplicaciones no requieren codigo PIC, si que necesitan la caracterfstica de 
direccionamiento indirecto que veremos en el siguiente apartado. Por esta 
razon las GCC 3.1 introdujeron la opcion -mdynamic-no-pic, la cual 
deshabilita el codigo PIC, pero mantiene los direccionamientos indirectos, 
necesarios para poder acceder a sfmbolos de una librerfa de enlace dinamico 1 . 

2.10.2. Direccionamiento indirecto 

El direccionamiento indirecto es el nombre que recibe una tecnica de 
generacion de codigo (separada del PIC) que permite acceder a los sfmbolos 
de una librerfa de enlace dinamico desde otra imagen (que puede ser una 
aplicacion o otra librerfa). Con esta tecnica una librerfa puede ser actualizada 
sin necesidad de actualizar la imagen cliente que la utiliza. 

Cuando se genera una llamada a una funcion definida en una librerfa de 
enlace dinamico el compilador, por cada funcion de librerfa que usa la imagen 
cliente, crea un stub de sfmbolo y un puntero a sfmbolo tardfo. El stub de 
si'mbolo es un trozo de codigo ensamblador que se encarga de ejecutar la 
funcion de librerfa. El puntero a sfmbolo tardio no es mas que un trozo de 
memoria donde se almacena un puntero a la funcion a ejecutar. La primera 
vez que se ejecuta la funcion el puntero a sfmbolo tardfo contiene la direccion 
de memoria de una funcion llamada dyid_stub_binding_heiper o la cual 
se encarga de enlazar el sfmbolo. Las demas veces el puntero a sfmbolo 
tardfo tendra la direccion real del sfmbolo a ejecutar. 

HilO de ejeCUCi6n dylb_stub_binding_helper ( ) 




Puntero a 
sfmbolo tardfo 

(LazySuma) 



Figura 3.2: Direccionamiento indirecto 

La Figura 3.2 muestra el proceso de direccionamiento indirecto. Cuando el 
hilo de la aplicacion llama al stub de sfmbolo (stubsuma en este ejemplo), 



1 Actualmente Xcode usa la opcion -mdynamic-no-pic por defecto al generar aplicaciones 
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este coloca en el registro maquina GPR11 su propia direccion y ejecuta la 
funcion cuya direccion este almacenada en el puntero a sfmbolo tardfo 
(Lazysuma en este ejemplo). La primera vez este puntero tendra la direccion 
de memoria de la funcion dyid stub binding heiper o con lo que esta se 
ejecutara recibiendo en el registro GPR11 la direccion del stub de sfmbolo, la 
cual le sirve para determinar que sfmbolo de librerfa enlazar. Despues la 

funcion dyid stub binding heiper ( ) ejeCUta la funcion Suma() y 

almacena la direccion de memoria de sumao en el puntero a sfmbolo tardfo. 
De esta forma las demas veces que se indireccione este puntero se ejecutara 
directamente la funcion suma o . 



2.11. Herramientas para ficheros binarios 
2.11.1. Herramientas para analizar ficheros Mach-0 

Ya hemos visto que para analizar un fichero Mach-0 disponemos de dos 
comandos nm y otool. 

El comando nm nos muestra la tabla de sfmbolos de un fichero de codigo 
objeto, sea este un . o, una librerfa o un ejecutable. Normalmente la salida de 
este comando tendra la forma: 

$ nm usuario . o 

OOOOOObc T _GetNombre 
00000140 D _Nombre 
0000004c T _SetNombre 
00000000 T SetNombre 

U _strcpy 

U _strlen 

U dyld_stub_binding_helper 



O prion 


Descri prion 


-a 


Muestra todos los sfmbolos, incluidos los de depuracion. 


-g 


Muestra solo los sfmbolos globales (externos). 


-u 


Muestra solo los sfmbolos indefinidos (undefined), es decir, los 
sfmbolos que han sido declarados pero no definidos por el modulo 
objeto. 


-m 


Muestra el segmento y seccion de cada sfmbolo, asf como 
informacion sobre si el sfmbolo es un sfmbolo externo o no externo. 


-s 


Muestra solo el segmento y seccion indicados. Para ello se usa esta 

Opcion de la forma -s segmento seccion. 



Tabla 3.4: Principales opciones del comando nm 



Donde cada sfmbolo esta precedido por un valor (o bianco si es un sfmbolo 
indefinido), despues ira una letra cuyo significado se detalla en la Tabla 3.2. 
Si el sfmbolo es privado aparecera en minusculas y si es un sfmbolo exportado 
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aparecera en mayusculas. La Tabla 3.4 resume las principales opciones del 
comando nm. 

El otro comando que tiene Mac OS X para analizar un fichero Mach-0 es el 
comando otooi 1 . Las distintas opciones de este comando se resumen en la 
Tabla 3.5. Todas estas opciones tienen dos modos. El modo numerico 
resumido que se da cuando solo indicamos la opcion, y el modo simbolico 
extendido que se da cuando tambien indicamos la opcion -v o -v. Cada 
opcion indica la informacion que queremos obtener. El comando otooi, a 
diferencia del comando nm, no puede ejecutarse sin opciones. 



Opcion 


Description 


-a 


■ i —j j_ i i _i i ■ /— « ■ 

Usado para mostrar la cabecera de un archivo. Supone que el 
fichero es un archivo (fichero .a). 


-S 


Muestra el contenido del fichero _. symdef, suponiendo que el 
fichero pasado sea un archivo (fichero . a). 


-f 


Muestra las cabeceras fat, suponiendo que el archivo sea un 
binario universal. 


— n 


ft A j_ 1 1 n yi 1 II C 1 

Muestra la cabecera Mach del fichero. 


T 
-J_l 


Muestra los nombres y numeros de version de las hbrenas de 
enlace dinamico que usa el fichero objeto. Vease el apartado 2.3. 


— Pi 


Muestra simplemente el nombre de instalacion de una librerfa de 
enlace dinamico. Vease apartado 2.4.1. 


-s 


Muestra solo el contenido de un segmento y seccion. Para ello 

USamOS la Opcion -s segmento seccion. 


-t 


Muestra el contenido de la seccion ( text, text) . Junto con 

la opcion -v desensambla su contenido, y con la opcion -v 
tambien desensambla simbolicamente los operandos. 


-d 


Muestra el contenido de la seccion ( data, data) . 


-o 


Muestra el contenido del segmento objc, usado por el runtime 

de Objective-C. 


-r 


Muestra el contenido de las entradas reasignables. Logicamente 
solo funciona con ficheros de codigo objeto (.o), y librerfas 
estaticas y dinamicas, pero no con ejecutables. 


-I 


Muestra la tabla de sfmbolos indirectos. 


-T 


Muestra la tabla de contenido de una librerfa de enlace dinamico. 


-R 


Muestra la tabla de referencias de una librerfa de enlace dinamico. 



Tabla 3.5: Principales opciones del comando otooi 



1 Este comando, al igual que el formato Mach-O, es propio del sistema Mac OS X, la mayoria 
de los sistemas UNIX disponen en su lugar del comando objdump. 
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2.11.2. Los simbolos comunes 

Los simbolos comunes son mas tfpicos en le lenguaje Fortran, pero tambien 
se usan en C para solucionar vicios comunes de los programadores. 

En C cuando se crea una variable global que va a ser usada por varios 
modulos, esta debe de declararse (preferiblemente en un fichero de 
cabecera) con el modificador extern en todos los modulos excepto en el que 
se define. 

En C tambien se permite que varios ficheros . c definan una variable global 
siempre que no la asignen un valor, tal como muestra el Listado 3.15 y 
Listado 3.16. 



/* modulol.c */ 

int global; 

int main ( ) 
{ 

return global; 
_} 

Listado 3.15: Modulo con variable global no inicializada 



/* modulo2 . c */ 
int global; 

Listado 3.16: Otro modulo con variable global no inicializada 

En caso de que las variables globales no esten inicializadas varios modulos 
pueden definir el mismo sfmbolo (que es lo que llamamos una variable 
comun) y durante el enlazado la variables comunes se fundiran en una sola: 

$ gcc -c modulol.c modulo2.c 

$ nm modulol.o modulo2.o 
modulol . o : 
00000004 C _global 
00000000 T _main 

modulo2 . o : 
00000004 C _global 

Vemos que las variables comunes aparecen marcadas con el tipo c (vease 
Tabla 3.2). Durante el enlazado las variables globales se fundiran en una sola. 

$ gcc modulol . o modulo2 . o -o modulol 
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2.11.3. Eliminar simbolos innecesarios 



El comando strip permite eliminar simbolos innecesarios de un fichero de 
codigo objeto. Esto puede resultar util para reducir el tamano de un programa 
o librerfa una vez que este ha sido depurado. 

Este comando no elimina todos los simbolos: los simbolos usados para el 
enlace dinamico nunca se eliminan, o sino el programa o librerfa dejarfan de 
funcionar. Pero si que es util eliminar los simbolos privados y los de 
depuracion. 



Por ejemplo si compilamos el Listado 1.1 y ejecutamos sobre el 
obtendrfamos gran cantidad de simbolos: 

$ gcc hola.c -o hola 
$ nm hola 

00003000 D _NXArgc 
00003004 D _NXArgv 

00002a30 T darwin_gcc3_preregister_f rame_inf o 

0000300c D progname 

00002bfc t stub_getrealaddr 

00002488 t call_mod_init_funcs 

00002584 t call_objcInit 

U cthread_init_routine 

00002798 t dyld_func_lookup 

00002740 t dyld_init_check 

00001000 A mh_execute_header 

00002210 t start 

U abort 



n m 



Muchos de los cuales son innecesarios y se pueden eliminar con strip: 



$ strip hola 
$ nm hola 

00003000 D _NXArgc 
00003004 D _NXArgv 
0000300c D progname 

U cthread_init_routine 

00001000 A mh_execute_header 

U abort 



El comando sobrescribe el fichero dado como argumento. Podemos enviar el 
resultado a otro fichero con la opcion -o: 



$ strip hola -o hola-release 



Tambien podemos ejecutar strip sobre una librerfa, e incluso sobre un 
fichero de codigo objeto metido dentro de una librerfa de enlace estatico de la 
forma: 



$ strip saludol . o libsaludos . a 
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3. Frameworks 



Un framework es una estructura jerarquica de directories donde se 
almacenan recursos compartidos, tales como librerfas de enlace dinamico, 
ficheros .nib, ficheros de cabecera, cadenas localizadas, y documentacion de 
referenda sobre el funcionamiento del framework, todo ello encapsulado en 
un solo paquete. Varias aplicaciones pueden usar todos estos recursos 
simultaneamente. Para ello el sistema va cargando en memoria todos estos 
recursos, segun los van necesitando las aplicaciones, y al ser recursos 
compartidos todos ellos ocupan la misma zona de memoria ffsica, aunque no 
necesariamente la misma direccion de memoria virtual de cada proceso. 

Un framework es un tipo de bundle 1 , que son conjuntos de ficheros que se 
agrupan de forma que desde el Finder se ven como un icono. Otros ejemplos 
de bundles son las aplicaciones o los plug-in de aplicacion. Los framework, a 
diferencia de los otros tipos de bundles no tienen el atributo que hace que 
Finder los muestre como un icono, sino que es posible usar el Finder para 
inspeccionar su contenido. Esto se hizo asf para facilitar al desarrollador 
moverse dentro del contenido del framework. 

La ventanas que introducen los framework respecto a las librerfas de enlace 
dinamico convencionales son: 

• El framework encapsula junto con la librerfa de enlace dinamico sus 
ficheros de cabecera y su documentacion 

• El framework puede tener otro tipo de recursos como iconos, ficheros 
.nib, o cadenas localizadas a cada lengua y pais. 

• Todos los recursos del framework, y no solo la librerfa de enlace 
dinamico, se pueden compartir en memoria entre las aplicaciones. 

La capa Darwin de Mac OS X esta implementada mediante librerfas de enlace 
estatico y enlace dinamico independientes, pero otros interfaces de 
programacion con Mac OS X estan implementadas como frameworks, como 
por ejemplo Carbon, Cocoa, o los Core Services. Estos interfaces estan 
agrupados bajo umbrella frameworks, que son frameworks que no 
contienen funcionalidad, sino que agrupan a otros frameworks. 

Ademas de usar los frameworks del sistema, el programador puede crear sus 
propios frameworks. En caso de que el framework este destinado a apoyar a 
una determinada aplicacion, y no a compartirlo con otros desarrolladores, 
serfa un framework privado. Por contra un framework publico serfa un 
framework destinado a ser compartido con otras aplicaciones, y en este caso 
se suele publicar su interfaz, para que otros desarrolladores lo puedan usar. 



1 Su contenido puede ser gestionado usando los Core Foundation Bundle Services, o la clase 
NSBundle de Cocoa. 
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3.1. Anatomia 

En Mac OS X, los recursos compartidos se empaquetan usando frameworks 
estandar y umbrella frameworks. Ambos frameworks tienen la misma 
estructura, aunque los umbrella frameworks anaden pequenos refinamientos 
a la estructura del framework estandar para permitir incorporar otros 
frameworks. 

Como ya hemos comentado, un framework es un tipo de bundle y se 
caracterizan por ser una carpeta con la extension .framework. En este 
apartado vamos a estudiar la estructura de ficheros y directorios de un 
framework estandar, y en el apartado 3.5 estudiaremos la estructura de los 
ficheros de los umbrella frameworks. 

Los framework estandar tienen la estructura de ficheros de la Figura 3.3 (a) 
donde las Ifneas discontinuas representan enlaces simbolicos. En el primer 
nivel encontramos dos enlaces a ficheros almacenados en subdirectories. El 
primero es Matematicas que apunta a la librerfa de enlace dinamico mas 
reciente de nuestra librerfa (observese que no tienen la extension .dyiib). El 
segundo es Headers que apunta a la carpeta de ficheros de cabecera mas 
reciente de la librerfa. Tambien en el primer nivel encontramos la carpeta 
versions donde se almacenan las versiones mayores de nuestra librerfa. 
Cuando una herramienta de desarrollo intenta acceder a un recurso del 
framework siempre accede a un recurso del primer nivel de directorios, pero 
si estos son un enlace, la llevaran a usar la ruta del recurso enlazado. 



Matematicas 



Headers 



Matematicas . framework 



Versions 




Matematicas 



Headers 



Versions 



B 



Matematicas 




Matematicas 



Headers 



Headers 



- Current 



' Current 



(a) Framework simple 



(b) Framework con dos versiones mayores 



Figura 3.3: Estructura de ficheros de un framework estandar 
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Dentro de la carpeta versions existira una carpeta por cada version mayor, 
etiquetada cada version sucesiva con los nombres a, b, etc 1 . Ademas estara la 
carpeta current que apunta a la version mayor mas moderna. Cada version 
contendra todo lo que deba encontrarse en el nivel superior del framework, 
por ejemplo, si el framework tiene iconos, estos deberan estar duplicados en 
cada version mayor, aunque hayan ido cambiando en las sucesivas versiones. 
Al existir enlaces a los recursos del primer nivel del framework (que son los 
unicos que existen para la herramienta de desarrollo) la librerfa puede ir 
evolucionando en el tiempo sin que la herramienta de desarrollo que la usa 
sea consciente. Solo las aplicaciones que usan el framework conoceran la 
verdadera ruta de los recursos, y de esta forma se mantiene compatibilidad 
hacia atras. 



eoe 


_2j Info. pi ist 












| New Sibling ) ( Delete 


) 


( Dump ') 








Property List 


Class 


Value 




Root 


Dictionary 


% 7 keyyvalue pairs 




CFBundleDevelopmentRegion 


String 


J English 




C FBu nd 1 e Executab 1 e 


String 


t Matematioas 




CFBundleHentifier 


String 


; org.macprogramadores.matematicas 




CFBundlelnfoDictionaryVersian 


String 


; 6.0 




CFBundlePackageType 


String 


; FMWK 




CFBundleSlgnatura 


String 


; ??7? 




C FBu ndle Version 


String 


; i.o 












1 







Figura 3.4: Contenido del fichero info.piist 



1 El nombre que se asigna a las versiones mayores no tiene porque ser necesariamente letras 
mayusculas sucesivas, pueden ser por ejemplo numeros, pero esta forma de versionado es la 
mas utilizada en el caso de los frameworks. 
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El recurso mas importante de cada version mayor es la librerfa de enlace 
dinamico, y es el unico obligatorio. La carpeta Headers es opcional, aunque 
muy usada cuando se crea un framework publico. 

Al igual que pasa con la carpeta Headers, en caso de que el framework tenga 
otros recursos, debera crearse una carpeta con los recursos en la 
correspondiente subcarpeta de version mayor dentro de versions, y un 
enlace simbolico en el primer nivel de la jerarqufa de directorios que apunte a 
la carpeta mas reciente con los recursos. Por ejemplo, cuando a Xcode le 
pedimos crear un framework, por defecto crea la carpeta Resources donde 
mete recursos como ficheros con texto localizado o un fichero llamado 
info.piist con informacion de localizacion del recurso como la que se 
muestra en la Figura 3.4. 

Otra carpeta que es comun encontrar en un framework es la carpeta 
Documentation, la cual contiene ficheros HTML o PDF que describen las 
funciones de la librerfa. 

Logicamente el programador puede crear carpetas con otros nombres en los 
que mete los recursos que considere necesario. 

3.2. Versionado de los frameworks 

En el apartado 2.2 vimos que las librerfas de enlace dinamico tenfan versiones 
mayores y versiones menores. Las versiones mayores permitfan la 
compatibilidad hacia atras, de forma que si actualizabamos la librerfa, 
aplicaciones enlazadas con una version mayor antigua segufan funcionando. 
Por contra las versiones menores, consegufan la compatibilidad hacia 
adelante, de forma que una aplicacion enlazada con una librerfa mas moderna 
podrfa seguir funcionando cuando la ejecutamos en un entrono donde exista 
una version mas antigua de la librerfa. Las versiones menores, ademas de ser 
compatibles hacia adelante, obligatoriamente deberan de ser compatibles 
hacia atras, o de lo contrarfo deberfamos de haber creado una nueva version 
mayor. 

Recuerdese que en el apartado 2.2.2 vimos que la version menor tenfa dos 
numeros: El numero de version actual que se fijaba con la opcion -current_ 
version, que permitfa numerar cada cambio que hacfamos a la librerfa, y la 
version de compatibilidad, que se fijaba con la opcion -compatibility 
version, y que permitfa conseguir la compatibilidad hacfa adelante, es decir, 
si entre dos librerfas no cambia el numero de version de compatibilidad (solo 
el numero de version actual), una aplicacion enlazada con la version mas 
moderna de la librerfa seguirfa funcionando si la ejecutamos en un entrono 
donde este instalada la version antigua de la librerfa. Luego, el tener la misma 
version de compatibilidad entre dos versiones de una misma librerfa indica 
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que la version mas antigua tiene exactamente la misma interfaz (y que como 
mucho, tiene errores o codigo menos optimizado). 

Las versiones menores en los frameworks se fijan con las mismas opciones de 
gcc que en las librerfas de enlace dinamico, pero las versiones mayores 
siguen el esquema de la Figura 3.3 (b). En la carpeta Versions puede haber 
mas de un directorio, en cuyo caso nuestro framework tiene varias versiones 
mayores. Aunque la herramienta de desarrollo siempre enlaza con la ultima 
version mayor, las aplicaciones enlazan con el fichero de librerfa de enlace 
dinamico cuya ruta es el directorio apuntado por el enlace simbolico en el 
momento en el que se compilo, con lo que una actualizacion de version 
mayor no afecta a las aplicaciones enlazadas con versiones mayores 
anteriores. 



3.3. Un framework de ejemplo 

En el aparado 3.3.1 vamos a hacer un ejemplo detallado donde se describen 
los pasos necesarios para crear un framework. En el apartado 3.3.2 veremos 
como se instala el framework. En el apartado 3.3.3 detallaremos como usar 
un framework desde una aplicacion. Por ultimo en el apartado 3.3.4 veremos 
como crear multiples versiones menores dentro de un framework. 

3.3.1. Crear un framework 

Lo primero que tenemos que hacer para crear un framework es crear la 
estructura de directories del framework. En nuestro ejemplo vamos a crear la 
estructura de directories de la Figura 3.3 (a): 

$ mkdir Matematicas . framework 
$ cd Matematicas . framework 
$ mkdir Versions 
$ cd Versions 
$ mkdir A 
$ cd A 

$ mkdir Headers 

$ cd . . 

$ In -s A Current 

$ cd . . 

$ In -s Versions/A/Headers/ Headers 

$ cd 

Lo siguiente que vamos a hacer es crear una librerfa donde solo 
implementamos la funcion de ejemplo suma o . El Listado 3.17 y Listado 3.18 
muestran como implementar esta librerfa. 



/* Matematicas . h */ 
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#ifndef _SUMA_H_ 
#define _SUMA_H_ 

int Suma(int a, int b) ; 

#endif 



Listado 3.17: Cabecera de la librerfa del framework 



/* Matematicas . c */ 

#include "Matematicas . h" 

int Suma(int a, int b) 
{ 

int c = a+b; 
return c; 



Listado 3.18: Implementacion de la librerfa del framework 

Ahora podemos generar la librerfa de enlace dinamico del framework: 

$ gcc Matematicas . c -dynamiclib -install_name /Library/Framework/ 
Matematicas . f ramework/Versions/A/Matematicas -current_version 1.0.0 
-compatibility_version 1.0.0 -o Matematicas 

Observese que hemos dado como nombre de instalacion la ruta /Library/ 

Framework/Matematicas . f ramework/Versions/A/Matematicas. EstO eS 

necesario hacerlo porque, como se explica en el apartado 3.3.2, los 
frameworks normalmente se instalan en una subcarpeta de la carpeta 
/Library/ Frame wo r ks. Como el nombre de instalacion se registra dentro de 
la aplicacion para que el cargador dinamico pueda encontrar la librerfa, 
durante la creacion de la librerfa es necesario indicar este nombre de 
instalacion. 



Tambien observese que el nombre de instalacion da la ruta ffsica de la librerfa 
dentro de su carpeta de version mayor, y no la ruta del enlace simbolico a la 
librerfa. Esto se hace para que al cambiar la version mayor del framework no 
cambie la librerfa con lo que estaban enlazadas las aplicaciones. 

Al crear la librerfa tambien hemos usado las opciones -current version y 
-compatibiiity version para indicar que la version menor, tanto actual 
como de compatibilidad, es la 1.0.0. 

Una vez tenemos creada la librerfa podemos copiarla a la carpeta del 
framework y crear el enlace a este fichero en el primer nivel: 

$ cp Matematicas Matematicas . framework/Versions/A/ 
$ In -s Matematicas . framework/Versions/A/Matematicas 
Matematicas . framework/ 
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Por ultimo copiamos el fichero de cabecera de nuestra librerfa a la carpeta 

Headers : 

$ cp Matematicas . h Matematicas . framework/Versions/A/Headers/ 

3.3.2. Instalar un framework 

Los frameworks creados por desarrolladores deben de ir en una de estas 
carpetas: 

• La mayorfa de los frameworks publicos se colocan en la carpeta 

/Library /Frameworks. 

• Si un framework va a ser usado por un solo usuario, podemos 
instalarlo en la carpeta -/Library/Frameworks del usuario. 

• Si un framework va a ser usado por muchos usuarios de una red, 

podemOS ponerlO en la Carpeta /Network/Library. 

Apple recomienda usar siempre la carpeta /Library/Frameworks y ha 
comenzado a desaconsejar el uso de las carpetas -/Library/Frameworks y 
/Network/Library. La primera porque si se pasa una aplicacion de la cuenta 
de un usuario a la de otro esta deja de funcionar, la segunda porque produce 
retrasos en el acceso a red, especialmente cuando no se puede acceder a 
esta. 

Lo que nunca debemos hacer es colocar nuestras librerfas en la carpeta 

/system/Library/Framework. Esta carpeta se la reserva Apple para sus 
propias librerfas. 

En nuestro ejemplo vamos a copiar el framework al directorio /Library/ 

Frameworks : 

$ mkdir /Library/Frameworks/Matematicas . framework 

$ cp -R Matematicas . framework /Library/Frameworks/Matematicas. 

framework 



3.3.3. Usar un framework 

Cuando enlazamos con un framework al enlazador estatico le tenemos que 
dar el nombre del framework con la opcion -framework seguida del nombre 
del framework sin extension. Por ejemplo para indicar que se enlace con 
nuestro framework llamado Matematicas . f ramewor k debemos de dar al 
comando id (o al comando gcc si preferimos usar el driver) la opcion - 

framework Matematicas. 
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Para que id encuentre el framework, este debe encontrarse en la carpeta 

/Library/ Framework 0 /System/Library/ Framewor k. Por defecto id no 

busca en ninguna otra carpeta, incluidas -/Library/Frameworks ni 

/Network/ Library. 

Si queremos que el framework se busque en otras carpetas tenemos dos 
opciones: Indicar a id donde buscarlo con la opcion -f, o indicar una lista de 
directories a buscar (separados por dos puntos) en la variable de entorno 

DYLD_FRAMEWORK_PATH. 

Imaginemos que queremos usar el framework que hemos creado antes, y 
para ello creamos el programa del Listado 3.19. 



/* usaf ramework */ 
#include <stdio.h> 

#include <Matematicas/Matematicas . h> 

int main ( ) 
{ 

printf("4+7 son %i\n" , Suma ( 4 , 7 ) ) ; 
return 0; 

} 

Listado 3.19: Programa que usa el framework Matematicas 

Todos los ficheros de cabecera puestos en la carpeta Headers de un 
framework con nombre Framework pueden ser accedidos de la forma: 

#include KFramework/ Cabecera . h> 

Donde Framework es el nombre del framework y cabecera es el fichero de 
cabecera (puesto en la carpeta Headers) a incluir. 

Por ejemplo, para acceder a nuestra librerfa usamos: 

#include <Matematicas/Matematicas . h> 

Observe que en ningun sitio vamos a usar la opcion -i para indicar donde 
esta instalado el fichero de cabecera, ya que basta con que el fichero de 
cabecera este en la carpeta Headers de un framework, para que este tipo de 
inclusion funcione. 

Ademas al ir a usar los ficheros de cabecera de un framework es tradicional 
incluir solo el fichero de cabecera maestro, que es el fichero de cabecera 
cuyo nombre coincide con el del framework, por ejemplo: 

# include <AddressBook/AddressBook . h> 
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AddressBook.h es el fichero maestro e incluira todos los ficheros de 
cabecera del framework que necesite. 

Luego la forma de poder hacer nuestra aplicacion que accede al framework 
sera: 

$ gcc usaf ramework . c -framework Matematicas -o usaframework 
$ . /usaframework 

4+7 son 11 

El comando: 

$ gcc usaframework . c -M 

usaf ramework . o : usaf ramework . c /usr/include/stdio . h 
/usr/include/_types . h \ 

/usr/include/sys/_types . h /usr/include/sys/cdef s . h \ 
/usr/include/machine/_types . h /usr/include/ppc/_types . h \ 
/Library/Frameworks/Matematicas . framework/Headers/ 
Matematicas . h 

Nos ayuda a ver que la inclusion de la ruta Matematicas/Matematicas .n ha 

SidO SUStituida por el preprOCesador por /Library/Frameworks/Matemati 
cas . f ramework/Headers/Matematicas .h. 



3.3.4. Crear multiples versiones de un framework 

Si ejecutamos el comando: 

$ otool -L 

/Library/Frameworks/Matematicas . framework/Versions/A/Ma tematic 
as 

/Library/Frameworks/Matematicas . f ramework/ Vers ions/ A/Matematic 
as : 

/Library/Framework/Matematicas . f ramework/Matematicas 
(compatibility version 1.0.0, current version 1.0.0) 
/ usr/lib/libgcc_s . 1 . dylib 

(compatibility version 1.0.0, current version 1.0.0) 
/ usr/lib/libmx . A . dylib 

(compatibility version 1.0.0, current version 92.0.0) 
/usr/lib/libSystem.B. dylib 

(compatibility version 1.0.0, current version 88.1.2) 

Vemos que el binario que hemos generado tiene como numeros de version 
menor (tanto actual como de compatibilidad) el valor 1 . o . o. 

En el apartado 3.2 dijimos que siempre que ibamos a realizar una 
actualizacion de nuestro software deberfamos de actualizar la version actual, 
y solo cuando hacfamos cambios en la interfaz (p.e. anadir una funcion) 
deberfamos de actualizar la version de compatibilidad, ya que las versiones 
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menores eran siempre compatibles hacia atras, pero no necesariamente hacia 
adelante, es decir, una aplicacion que enlazase con una version superior no 
tenia garantizado el poder ejecutarse en un entorno donde esta instalada una 
version anterior, a no ser que las version de compatibilidad fuesen las 
mismas. 

Vamos a modificar ahora el programa del Listado 3.18 para optimizar la 
funcion suma o de forma que no use una variable temporal 1 de la forma: 

int Suma(int a, int b) 
{ 

return a+b; 

} 

Como este cambio es solo una mejora de rendimiento, y no afecta a la 
interfaz, podemos recompilar la aplicacion cambiando solo la version actual y 
manteniendo la version de compatibilidad. Luego podemos recompilar la 
librerfa de la forma: 

$ gcc Matematicas . c -dynamiclib -install_name /Library/Framewo 
rk/Matematicas . f ramework/Versions/A/Matematicas -current_versi 
on 1.0.1 -compatibility_version 1.0.0 -o Matematicas 

Y la aplicacion usaframework seguira funcionando sin necesidad de 
recompilarla. 

Si ahora decidiesemos anadir al programa del Listado 3.18 una funcion 
Resta o de la forma: 

int Resta (int a, int b) 
{ 

return a-b; 

Entonces no solo deberfamos de aumentar la version actual, sino que 
aumentamos la version de compatibilidad de la forma: 

$ gcc Matematicas . c -dynamiclib -install_name /Library/Framewo 
rk/Matematicas . f ramework/Versions/A/Matematicas -current_versi 
on 1.1.0 -compatibility_version 1.1.0 -o Matematicas 

Aunque no es norma, si que se acostumbra a aumentar el tercer dfgito de la 
version cuando se hacen mejoras compatibles hacia adelante consistentes en 
mejoras del rendimiento o se arreglan bugs, mientras que cuando se ahade 
funcionalidad no compatible hacia adelante se modifica el segundo dfgito. Por 
ultimo el primer dfgito se suele incrementar cuando se cambia la version 
mayor. 



1 Esta optimizacion la hubiera realizado automaticamente gcc si hubieramos activado la 
optimizacion con la opcion -o. 
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3.4. Frameworks privados 

Ademas de los frameworks publicos, las aplicaciones tienen frameworks 
privados, que son frameworks que en vez estar destinados a ser compartidos 
entre varias aplicaciones, estan destinados a ser usados solo por una 
aplicacion. 

La ventaja de los frameworks privados es que la aplicacion siempre tiene la 
version correcta del framework. El inconveniente esta en que no son 
compartidos entre varias aplicaciones. 

Normalmente los frameworks privados se usan para que dentro de una 
aplicacion grande se puedan desarrollar modulos mas pequenos que no estan 
destinados a ser compartidos con otras aplicaciones, sino a uso exclusivo por 
parte de nuestra aplicacion. 

Estos frameworks deben de almacenarse en un subdirectorio con el nombre 
Frameworks dentro del bundle de la aplicacion. La Figura 3.5 muestra como 
organiza la aplicacion Keynote los ficheros de su bundle. En la subcarpeta 
Macos encontramos el fichero Keynote, que es el ejecutable de la aplicacion. 
En la subcarpeta Frameworks encontramos dos frameworks privados. 

Keynote . app 

I Content 

MacOS 

I Keynote 

Frameworks 

BGSaveLoad . framework 

ModelFramework . framework 

Figura 3.5: Ejemplo de frameworks privados 

Los frameworks privados tienen siempre como comienzo del nombre de 
instalacion el valor @executabie_patn/ .. /Frameworks. Por ejemplo el 
nombre de instalacion de la librerfa de enlace dinamico del framework 

BGSaveLoad . framework de la Figura 3.5 Serfa @executable_path 
/. . /Frameworks/BGSaveLoad. f ramework/Versions/A/BGSaveLoad, que 

es la ruta donde se encuentra alojada la librerfa de enlace dinamico del 
framework respecto a la aplicacion. 
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3.5. Los umbrella frameworks 

Los umbrella frameworks son una forma de agrupar varios frameworks en 
un solo framework. Esto permite ocultar al programador complejas 
dependencias entre los subframeworks. Ademas de esta forma el 
programador no tiene porque saber que frameworks debe de importar y que 
dependencias existen entre los frameworks. 

La estructura de un umbrella framework es similar a la de un framework 
normal, excepto en dos aspectos: El primero es que, como muestra la Figura 

3.6, disponen de una carpeta con el nombre Frameworks donde se 
almacenan los subframeworks que lo componen. El segundo es que la carpeta 
Headers no contiene todos los ficheros de cabecera de cada subframework, 
sino que solo contiene un fichero de cabecera maestro (Quartz. h en la 
Figura 3.6) el cual incluye todos los ficheros de cabecera de los 
subframeworks que hagan falta. Nunca debemos de incluir en nuestro 
programa los ficheros de cabecera de los subframeworks directamente, de 
hecho los ficheros de cabecera de los subframeworks tienen protegida su 
inclusion directa. Para ello los propios ficheros de cabecera detectan que falta 
por definir un identificador del fichero maestro y usan la directiva terror 
para avisar al programador de que lo correcto es incluir el fichero maestro. 

En la Figura 3.6 tambien vemos la librerfa de enlace dinamico Quartz, que lo 
que hace es depender de las librerfas de enlace dinamico de los 
subframeworks de forma que al cargar la librerfa de enlace dinamico del 
umbrella frameworks se cargan las librerfas de enlace dinamico de los 
subframeworks. 

Logicamente un umbrella framework puede a su vez incluir otros umbrella 
frameworks creando estructuras mas complejas. 

Apple no recomienda a los desarrolladores externos crear umbrella 
frameworks, aunque permite hacerlo y proporciona herramientas para ello. La 
razon que da es que los umbrella frameworks son agrupaciones demasiado 
grandes y normalmente un framework no deberfa de tener tanta complejidad. 
Segun Apple los unicos frameworks lo suficientemente complicados como 
para necesitar crear umbrella frameworks son los frameworks que 
implementan la funcionalidad del sistema operativo, y que se encuentran en 

la Carpeta /System/Library/Frameworks. 
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Quartz . framework 
Quartz 

Headers. 



Frameworks 






Versions 






u 










r 






Quartz 






Headers 








1 Quartz. h 




Frameworks -4 



PDFKit . framework 

QuartzComposer . framework 
Figura 3.6: ejemplo de umbrella framework 
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Tema 4 



Compilando en 

C++ 



Sinopsis: 



En este tema pretendemos detallar el funcionamiento del compilador en lo 
que a I lenguaje C++ concierne. En concreto estudiaremos las opciones 
particulares del compilador en lo que a C++ se refiere y las extensiones no 
estandar introducidas para el lenguaje. 

En este tema tambien veremos aspectos referentes al name mangling de 
C++, y a como crear cabeceras precompiladas, las cuales mejoran 
considerablemente el tiempo de compilacion de un programa. 
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l.EI compilador de C++ 



Muchas de las opciones del compilador de C son heredadas por el compilador 
de C++, con lo que en este tema solo trataremos las opciones especfficas de 
C++. Logicamente, antes de leer este tema conviene haber lefdo el Tema 2. 

Los ficheros C++ se caracterizan por tener la extension . cc o . cpp. Si 
suponemos que tenemos un fichero de codigo fuente como el del Listado 4.1, 
podemos compilarlo con el comando: 

$ g++ hola.cpp -o hola 



/* hola.cpp */ 

#include <iostream> 
using namespace std; 

int main ( ) 
{ 

cout << "Hola mundo" << endl; 
return 0; 

} 

Listado 4.1: Programa mfnimo C++ 

El comando g++ es un comando que se limita a llamar a gcc anadiendo la 
opcion de enlazado -istdc++ la cual hace que se use la librerfa de enlace 
estatico iibstdc++.a durante el enlazado. Esta librerfa tiene las funciones y 
clases de C++. 

Observe que si ejecuta: 

$ gcc hola.cpp -o hola 

/usr/bin/ld: Undefined symbols: 

std: :basic_ostream<char, std: :char_traits<char> 

>: :operator<< (std: : basic_ostream<char , std : : char_traits<char> 
>& (*) ( std : : basic_ostream<char , std : : char_traits<char> >&) ) 
std : : ios_base ::Init::Init() 
std : : ios_base ::Init::~Init() 
std : : cout 

collect2 : Id returned 1 exit status 

El enlazador fallara por no encontrar los sfmbolos de la librerfa de C++. 
Logicamente siempre puede ejecutar el comando de la forma: 

$ gcc hola.cpp -lstdc++ -o hola 
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En muchos sistemas (incluido Mac OS X) tambien existe el comando c++ que 
es identico a g++: 

$ C++ hola.cpp -o hola 

De hecho, actualmente tanto c++ como g++ son enlaces al compilador actual 
de C++ (p.e. g++-4.o). Igualmente tanto el comando cc como gcc son 
enlaces al compilador de C actual (p.e. gcc-4.0). Como se explico en el 
apartado 5 del Tema 2, estos enlaces se pueden cambiar a otra version del 
compilador usando el comando gcc seiect. 



/* nombref uncion . cpp */ 

#include <iostream> 
using namespace std; 

int Funcionl (int a, int b) 
{ 

cout « "Dentro de " « 
cout << "Dentro de " << 
cout « "Dentro de " « 
return 0; 

} 

class X 
{ 

public : 

int metodol (double d) 
{ 

cout << "Dentro de 
cout << "Dentro de 
cout << "Dentro de 

} 

}; 

int main ( ) 
{ 

Funcionl (2,4) ; 
X x; 

x .metodol (3.7) ; 

return 0; 

_} 

Listado 4.2: Programa que usa pretty_function 



tunc << endl; 

_FUNCTION « endl; 

PRETTY FUNCTION « endl; 



" « tunc « endl; 

" « FUNCTION « endl; 

" « PRETTY FUNCTION « endl; 
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2.Extensiones al lenguaje C++ 



En esta segunda parte del tema comentaremos algunas extensiones al 
lenguaje C++ introducidas por las GCC. Al igual que en el caso de C es 
posible que muchas de estas opciones sean aceptadas por los organismos de 
estandarizacion ANSI y ISO en futuras revisiones del lenguaje C++. 

2.1. Obtener el nombre de una funcion y metodo 

En el apartado 3.9 vimos que la palabra reservada function , o su 

version estandar ISO 99 func , devolvfan el nombre de la funcion C 

dentro de la que se encontraban. 

Si estamos programando en C++, junto con las anteriores palabras 

reservadas, tenemos la palabra reservada pretty function , que 

ademas de devolver el nombre de la funcion o metodo donde se encuentre 
situada, devuelve los parametros y retorno de la funcion. 

Por ejemplo, si ejecutamos el programa del Listado 4.2 obtendrfamos la 
siguiente salida: 

$ . /nombref uncion 

Dentro de Funcionl 

Dentro de Funcionl 

Dentro de int Funcionl (int, int) 

Dentro de metodol 

Dentro de metodol 

Dentro de int X : rmetodol (double) 



2.2. Los operadores ?> y ?< 

Estos operadores tambien son una extension de las GCC al lenguaje C++ que 
permiten obtener el maximo o minimo de sus operandos. 

Por ejemplo, para obtener el minimo o maximo de dos numeros harfamos 
respectivamente: 

int min = a <? b; 
int max = a >? b; 

Estos operadores tambien se pueden sobrecargar. El Listado 4.3 muestra un 
ejemplo con el operador >? sobrecargado. 
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/* Numero.cpp */ 

#include <iostream> 
using namespace std; 

class Numero 
{ 

friend Numero operator>? (const NumeroS n, const NumeroS n2); 
private : 

int n; 
public : 

Numero (int n) :n (n) { } 

int getNumero() const {return n;}; 

}; 

Numero operator>? (const NumeroS n, NumeroS n2) 
{ 

return Numero (n . getNumero ( ) >? n2 . getNumero ()) ; 

} 

int main ( ) 
{ 

Numero nl ( 4 ) ; 
Numero n2 (3) ; 
Numero n3 = nl >? n2 ; 

cout << "El maximo es " << n3 . getNumero ( ) << endl; 
return 0; 



Listado 4.3: Ejemplo de sobrecarga del operador >? 
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3.Name mangling 



Como ya sabemos, C++ usa name mangling para representar los sfmbolos, 
luego si ejecutamos nm sobre un fichero de codigo objeto: 

$ nm Numero . o 

00000000 W _ZN6NumeroClEi 
00000000 W _ZNK6Numero9getNumeroEv 

U _ZNKSs4sizeEv 

U _ZNKSsixEj 
0000014c T main 

Obtenemos los sfmbolos con name mangling. Podemos usar la opcion -- 
demangie de nm para eliminar el name mangling. 

$ nm --demangie Numero. o 

00000000 W Numero: :Numero (int) 
00000000 W Numero :: getNumero ( ) const 
U std :: string :: size ( ) const 

U std :: string :: operator [ ] (unsigned int) const 
0000014c T main 



Pag 101 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 

4.Cabeceras precompiladas 



Los compiladores de C y C++ actualmente pasan la mayorfa de su tiempo 
compilando una y otra vez cabeceras mucho mas grandes que el codigo 
fuente del fichero . c o . cpp en si. El compilador de GNU a partir de la version 
3.3 incluye la posibilidad de usar cabeceras precompiladas, la cual acelera 
mucho la compilacion de programas C y C++. En este apartado se explica 
como aprovechar esta nueva caracterfstica 

Para facilitar la explicacion de las cabeceras precompiladas, supondremos que 
nuestros ficheros fuente incluyen en su mayorfa el fichero <iostream> con 
las operaciones tfpicas de entrada/salida C++, y el fichero <math.h> con las 
operaciones matematicas mas normales. 

En consecuencia hemos decidido crear un fichero precompilado con estos 
ficheros de cabecera, con el fin de acelerar la compilacion de nuestro 
proyecto. El fichero de cabecera, en general, debera incluir solo ficheros de 
cabecera que cambien poco, preferiblemente solo los que vienen con el 
compilador (los que tienen nombres #±nciude <...>), y no los ficheros de 
cabecera de nuestro programa (que tienen nombres tinciude ". . ."), ya 
que sino tendrfa que recompilarse el fichero de cabecera cada vez que 
modificaramos uno de nuestros ficheros .h. 

Los ficheros de cabecera precompilados tienen el mismo nombre que el 
fichero .h correspond iente, pero con el sufijo .gch. Por ejemplo si creamos el 
fichero precompiled. h con las cabeceras comunes que incluye nuestro 
proyecto, el fichero de cabecera precompilado se debera llamar 

precompiled . h . gch. 

El fichero que nosotros hemos creado como ejemplo es: 

$ cat precompiled. h 

#include <iostream> 
#include <math.h> 
using namespace std; 

Lo siguiente que tenemos que hacer es precompilar este fichero, para lo cual 
ejecutamos: 

$ g++ -c precompiled. h -o precompiled. h . gch 

Lo cual nos crea el fichero precompiled, n. gch con todos los ficheros 
incluidos por precomp iied.h precompilados. 

Ahora si, por ejemplo, el fichero encuadre.cpp incluye el fichero 

precomp iied.h, cuando ejecutemos: 
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$ g++ -c encuadre.cpp -o encuadre.o 

El compilador de GNU buscara primero en el disco un fichero llamado 
precompiled. h.gch, si lo encuentra lo usara, y solo si no lo encuentra 

induira precompiled. h. 

Aquf conviene hacer varias apreciaciones: La primera es que para que el 
compilador de GNU use el fichero .gch que encuentre, este debera estar 
compilando exactamente con las mismas opciones con las que hemos lanzado 
la compilacion de encuadre.cpp, es decir basta con que hubieramos usado: 

$ g++ -01 -c encuadre.cpp -o encuadre.o 

Para que no nos acepte el fichero precompilado y use el sin precompilar. 

La segunda apreciacion es que el compilador de GNU requiere un fichero 
precompilado para cada dialecto de C (C, C++, Objective-C). Si quisiesemos 
que un fichero precompilado se usase por distintos dialectos de C, 
necesitanamos crear uno distinto para cada dialecto (usando la opcion -x c- 

header, -x c+ + -header y -x ob j ective-c-header). En este CaSO la forma 

de proceder es crear un directorio con el nombre precompiled. h.gch y 
dentro de el meter todos los ficheros precompilados para todos los dialectos 
que estemos usando (da lo mismo el nombre que demos a estos ficheros, gcc 
examina todos los ficheros del directorio en busca del que necesite). 

La tercera apreciacion es que si vamos a usar ficheros precompilados en un 
fichero Makefile conviene crear una regla que actualice los ficheros de 
cabecera precompilados como la siguiente: 

encuadre.o: encuadre.cpp encuadre.h Matriz.h Punto.h 
precompiled . h . gch 

precompiled . h . gch : precompiled . h 

$(CXX) $ A $(CXXFLAGS) -o $@ 

Desgraciadamente actualmente make no soporta el uso de reglas implfcitas 
para los ficheros precompilados. 
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5.Un parche para el enlazador 



En muchos lenguajes orientados a objeto, como C++, es necesario que el 
programa ejecute constructores estaticos antes de que el hilo principal del 
programa empiece a ejecutar. Al enlazador le resulta extremadamente diffcil 
modificar el codigo objeto para anadir estas inicializaciones con lo que las 
GCC optaron por solucionar este problema con el comando collect2. 

El driver gcc actualmente en vez de enlazar codigo C++ ejecutando el 
comando id, enlaza ejecutando el comando coiiect2. Este comando detecta 
constructores estaticos que deban de ser ejecutados antes de que empiece la 
ejecucion de la funcion main o (es decir, sfmbolos marcados con el atributo 

constructor), genera un fichero .c temporal con una funcion main o que 

llama a estos constructores, compila el fichero temporal y altera main o para 

que Name a main o . Una vez hecho esto coiiect2 ya puede llamar a id 

para que realice el enlazado real. 

El comando coiiect2 recibe las mismas opciones que id, y transmite a id 
las opciones recibidas. El comando coiiect2 no solo llama a id, sino que 
despues llama a strip para eliminar sfmbolos innecesarios del binario 
generado. 
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Tema 5 



Compilando en 

Java 



Sinopsis: 



Java es diferente a los otros lenguajes soportados por las GCC respecto a que 
en los demas lenguajes el compilador genera un binario ejecutable, mientras 
que Java genera bytecodes ejecutables en una maquina virtual. 

El compilador Java de las GCC se diferencia de otros compiladores Java en 
que, no solo es capaz de generar bytecodes, sino que ademas es capaz de 
convertir estos bytecodes en codigo binario directamente ejecutable en la 
plataforma destino. Esta peculiaridad permite generar codigo Java que 
ejecuta considerablemente mas rapido que su correspondiente version de 
bytecodes. En este tema estudiaremos como llevar esto a cabo. 
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1. Compilando Java con las GCC 



Para que una clase Java sea ejecutable debe de tener un metodo estatico 
main o como el del Listado 5.1. 



public class HolaMundo 
{ 

public static void main ( String [ ] args) 
{ 

System . out.println ( "Hola mundo" ) ; 

} 



Listado 5.1: Programa mfnimo Java 

Como sabra, este programa se puede compilar con el compilador javac y 
ejecutar asf: 

$ javac HolaMundo . java 
$ Is -1 HolaMundo . class 

-rw-r— r— 1 fernando admin 422 Feb 5 14:29 HolaMundo . class 
$ time java HolaMundo 

Hola mundo 
real 0ml. 126s 
user 0m0.310s 
sys 0m0.198s 

Si lo que queremos es generar un binario, debemos usar el comando gcj 1 
con la opcion --main , la cual usamos para indicar la clase donde esta el 
metodo main O de la forma: 

$ gcj - -main=HolaMundo HolaMundo . java -o HolaMundo 
$ time HolaMundo 

Hola mundo 
real 0m0.286s 
user 0m0.097s 
sys 0m0.088s 

En este ejemplo puede apreciar la mejora en rendimiento temporal que 
conseguimos con la compilacion binaria. 



1 Tenga en cuenta que, como indicamos en el apartado 3 del Tema 1, el comando gcj, al 
igual que otros muchos comandos que vamos a ver en este tema, no viene con las Developer 
Tools de Apple, sino que debera instalarselo de otra distribucion, como por ejemplo Fink. 
Ademas, al menos en el momento de escribir este tutorial, las gcj tool estaban marcadas 
como inestables en Fink, con lo que nos ha sido necesario habilitar el branch 
unstable/main para que Fink sf que las instalase. 
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Tenga en cuenta que, como los binarios ejecutables estan libres de la 
convencion de nombres Java, el nombre de fichero de salida que demos a la 
opcion -o no tiene porque llamarse igual que la clase. 

La diferencia de rendimiento que hemos mostrado mas arriba es un poco 
enganosa ya que las GCC, al menos en el momento de escribir este 
documento, generan bytecodes mas optimizados que la herramienta javac 
de Apple. 

Es decir, podemos pasar el programa del Listado 5.1 a bytecodes con el 
comando gcj y la opcion -c: 

$ gcj -C HolaMundo . java 
$ Is -1 HolaMundo . class 

-rw-r— r— 1 fernando admin 406 Feb 5 14:28 HolaMundo . class 

Donde puede observar que el fichero de bytecodes tiene menos bytes que 
cuando lo compilamos con j avac de Apple. 

Podemos ejecutar ahora estos bytecodes tanto con el comando java de 
Apple, como con el comando gij de las GCC: 

$ time java HolaMundo 

Hola mundo 

real 0m0.699s 

user 0m0.306s 

sys 0m0.187s 

$ time gij HolaMundo 

Hola mundo 

real 0m0.358s 

user 0m0.124s 

sys 0m0.093s 

Donde vemos que las GCC no solo generan bytecodes mas optimizados, sino 
que la maquina virtual de las GCC ejecuta los bytecodes mas rapido que la 
maquina virtual de Apple. 

Observese que para compilar a bytecodes hemos usado la opcion -c, ya que 
-c sirve, al igual que normalmente, para generar un fichero de codigo objeto: 

$ gcj HolaMundo . java -c 
$ nm HolaMundo . o 

0000016c d CD_HolaMundo 

00000174 d CT_HolaMundo 

000000c8 s Utfl 

00000000 T ZN9HolaMundo4mainEP6JArrayIPN4 java41ang6StringEE 

O si preferimos generar codigo ensamblador tambien podemos usar la opcion 

-s: 
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$ gcj -S HolaMundo . java 

Conviene comentar que ademas de aceptar codigo fuente Java, gcj tambien 
acepta bytecodes: 

$ gcj HolaMundo . class --main=HolaMundo -o HolaMundo 

0 incluso podemos darle como entada un fichero .jar, del cual gcj saca la 
clase indicada y la compila para generar el ejecutable: 

$ jar cf libsaludos . jar HolaMundo . class 

$ gcj --main=HolaMundo libsaludos . jar -o HolaMundo 

Ahora para ejecutar el programa no necesitarfamos adjuntar el fichero .jar: 

$ rm libsaludos . jar 
$ . /HolaMundo 

Hola mundo 
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2.Utilidades Java de las GCC 



Las GCC, ademas de los comandos gcj y gij traen otros muchos comandos 
de utilidad para Java que se resumen en la Tabla 5.1. 



Comando 


Description 


gcj 


Compilador Java de las GCC. 


gij 


Interprete Java de las GCC. 


gcjh 


Los metodos nativos Java se pueden escribir tanto en el 
estandar JNI (Java Native Interface) de Sun, como en CNI 
(Compiled Native Interface), una interfaz C++ para metodos 
nativos desarrollada por las GCC. El comando gcjh nos permite 
generar los prototipos CNI (o JNI si usamos la opcion -jni) de 
los metodos a implementar. 


j cf -dump 


Nos permite obtener informacion sobre el contenido de un 
fichero .class. Usando la opcion -javap podemos obtener la 
salida en el mismo formato que el comando javap de Sun. 


j v-scan 


Recibe un fichero de codigo fuente Java y produce distintas 
informaciones sobre este. Por ejemplo, con la opcion -- 
complexity nos devuelve la complejidad ciclomatica de cada 
clase. Consulte man para una informacion mas detallada. 


grep j ar 


Busca una expresion regular en un fichero .jar. Por ejemplo 

grep jar "main" libsaludos . j ar buSC3 la palabra main en 
lOS ficherOS de libsaludos . j ar. 


f ast j ar 


Una implementacion del comando jar de Sun que ejecuta 
considerablemente mas rapido. 



Tabla 5.1: Comandos Java de las GCC 
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Tema 6 

Combinar 
distintos 
lenguajes 



Sinopsis: 



En este tema vamos a comentar los detalles necesarios para combinar 
programas escritos en distintos lenguajes. 

Debido a que las GCC utilizan el mismo backend para producir codigo objeto 
para los distintos lenguajes, resulta relativamente sencillo combinar 
programas escritos en distintos lenguajes. 

En cualquier caso el programador debera tener en cuenta una serie de 
aspectos relativos al nombrado de simbolos en los distintos lenguajes, name 
mangling, paso de argumentos, conversion entre tipos de datos, manejo de 
errores y librenas de runtime de los distintos lenguajes. 
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l.Combinar C y C++ 



El lenguaje C y C++ combinan de forma natural debido a que C++ se diseno 
como una extension a C. Una consecuencia es que el mecanismo de paso de 
parametros de ambos lenguajes es el mismo. 

Una diferencia la encontramos en el mecanismo de nombrado de sfmbolos. 
Mientras que en C los sfmbolos usados para referirse a los nombres de las 
funciones no usan los parametros, en C++ estos sfmbolos siempre incluyen 
informacion sobre los parametros de la funcion. Sin embargo vamos a ver que 
C++ tiene un mecanismo para poder referirse a las funciones usando 
sfmbolos con la convention de nombrado de C. 



1 .1 . Llamar a C desde C++ 

El Listado 6.1 muestra un programa C++ que ejecuta la funcion C definida en 
el Listado 2.4. Para ello el programa C++ declara el prototipo de la funcion C 
con el modificador extern "c. 



/* pidesaludo . cpp */ 

extern "C" void Saluda (); 

int main ( ) 
{ 

Saluda () ; 
return 0; 

} 

Listado 6.1: Programa C++ que ejecuta una funcion C 

Para compilar los dos modulos y generar el ejecutable podemos usar: 

$ g++ -c pidesaludo . cpp 
$ gcc -c saluda.c 

$ gcc saluda.o pidesaludo. o -lstdc++ -o pidesaludo 

Observese que hemos necesitado incluir la librerfa de C++ durante el 
enlazado. 

Como normalmente un programa C++ necesita acceder a mas de una funcion 
C, es mas comun declarar estas funciones de la forma: 

extern "C" { 
void Saluda ( ) ; 
int Suma(int a, int b) ; 
void DespideO; } 
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Como las declaracion de las funciones se suele hacer en un fichero de 
cabecera, es muy comun encontrar una declaracion que sirva tanto para C 
como para C++ de la siguiente forma: 

#ifdef cplusplus 

extern "C"{ 
#endif 

void Saluda ( ) ; 

int Suma(int a, int b) ; 

void Despide ( ) ; 

#ifdef cplusplus 




Donde el identificador cplusplus es un identificador que solo esta definido 

cuando compilamos con el compilador de C++. 

1 .2. Llamar a C++ desde C 

Para que un programa C pueda llamar a una funcion C++ es necesario que la 
funcion C++ sea declarada con el modificador extern "C", de esta forma el 
sfmbolo que genera el compilador de C++ para esta funcion sera compatible 
con el nombrado de sfmbolos de C. 

El Listado 6.2 muestra una funcion C++ declarada con un nombrado de 
sfmbolo al estilo C. Observese que aunque el prototipo es de tipo C, la 
implementacion de la funcion puede tener instrucciones propias del lenguaje 
C++. 



/* saludocpp . cpp */ 

#include <iostream> 

extern "C" void SaludoCPP() 
{ 

std::cout << "Hola desde C++" « std::endl; 
} 

Listado 6.2: Funcion C++ llamable desde C 

Si compilamos este modulo y usamos nm para obtener informacion sobre sus 
sfmbolos veremos que el sfmbolo saludocpp sigue la convencion de 
nombrado de C: 
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$ g++ -c saludocpp . cpp 
$ nm saludocpp. o 

00000000 T _SaludoCPP 
U ZSt4cout 

Podemos hacer un programa C como el del Listado 6.3 que llama a la funcion 
C++ (definida con prototipo al estilo de C). 



/* pidesaludo . c */ 

void SaludoCPP ( ) ; 

int main ( ) 
{ 

SaludoCPP () ; 
return 0; 

} 

Listado 6.3: Programa C que llama a una funcion implementada en C++ 

Y podemos compilar este modulo C y enlazarlo con el modulo C++ de la 
forma: 

$ gcc -c pidesaludo. c 

$ gcc pidesaludo. o saludocpp. o -lstdc++ -o pidesaludo 
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2. Acceso a C desde Java 



Podemos usar JNI (Java Native Interface) para comunicarnos entre clases 
Java ejecutando en una maquina virtual y librerfas de enlace dinamico nativas 
escritas en C, C++ o ensamblador 1 . 

JNI fue disenado, y es mas util, cuando un programa que se esta ejecutando 
en una maquina virtual Java quiere acceder a funcionalidad nativa del sistema 
donde se esta ejecutando. En el apartado 2.4 veremos que tambien se puede 
usar JNI cuando un programa C quiere acceder a funcionalidad de una clase 
Java. 

Hay que tener en cuenta que el acceso desde Java a funcionalidad nativa 
elimina el principio de independencia de la plataforma que caracteriza a los 
programas Java. Aunque esta limitacion se puede paliar en parte escribiendo 
la librerfa nativa para varios sistemas. 



2.1. Una clase Java con un metodo nativo 

La forma mas usada por JNI para combinar C y Java es crear una clase Java 
con un metodo nativo, es decir un metodo que ejecuta codigo C. 

Logicamente el metodo nativo tambien podrfa estar implementado en C++ o 
incluso en ensamblador, pero vamos a suponer que lo vamos a implementar 
en C. 



/* HolaNativo . j ava */ 

public class HolaNativo 
{ 

static { 

System . loadLibrary ( "HolaNativo . dylib" ) ; 

} 

public static void main ( String [ ] args) 
{ 

HolaNativo h = new HolaNativo () ; 
h . saluda ( ) ; 

} 

public native void saluda (); 
_} 

Listado 6.4: Clase Java con un metodo nativo 



1 En este apartado vamos a resumir como funciona JNI. Si desea profundizar en esta 
tecnologfa puede consultar el "Tutorial de JNI" que tenemos publicado en la web de 

macprogramadores . org. 
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Como ejemplo, el Listado 6.4 muestra una clase con un metodo nativo 
saiudao, y un metodo maino que ejecuta el metodo nativo. El metodo 
nativo se declara como parte de la clase, pero no se implementa, ya que su 
implementacion se encuentra en una librerfa de enlace dinamico. La clase 
tambien tiene un inicializador estatico que llama al metodo estatico system. 
loadLibrary ( ) para cargar la librerfa de enlace dinamico que tiene el 
metodo nativo implementado. 

Podemos compilar la clase Java con el comando: 

$ gcj -C HolaNativo . java 

Una vez tengamos el fichero HolaNativo . class, podemos ejecutar el 
comando gcjh con la opcion -jni de la forma: 

$ gcjh -jni HolaNativo 

Este comando genera un fichero con el nombre HolaNativo. h que contiene 
el prototipo de la funcion que debemos implementar para responder a las 
llamadas al metodo nativo. 

$ cat HolaNativo . h 

/* DO NOT EDIT THIS FILE - it is machine generated */ 

#ifndef HolaNativo 

tdefine HolaNativo 

#include <jni.h> 

#ifdef cplusplus 

extern "C" 
{ 

#endif 

JNIEXPORT void JNICALL Java_HolaNativo_saluda (JNIEnv *env, 
j ob j ect) ; 

#ifdef cplusplus 

} 

#endif 

#endif /* HolaNativo */ 

Vemos que el nombre de la funcion a implementar esta formado por el 
sfmbolo java_ seguido del nombre de la clase y del nombre del metodo a 
implementar. En el ejemplo este nombre sera java HoiaNativo saiuda o . 
Ademas las funciones que implementan el metodo nativo siempre tienen al 
menos dos parametros (a pesar de que el metodo Java no tenga 
parametros). El primer parametro es un puntero a informacion de entorno de 
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JNI, y el segundo es un puntero al objeto sobre el que se ejecuta el metodo 
(es decir, el puntero this del objeto Java). 



Podemos implementar la funcion del metodo nativo como muestra el Listado 
6.5. 



/* HolaNativo.c */ 




#include <jni.h> 




#include "HolaNativo . h" 




void JNICALL Java HolaNativo saluda 


(JNIEnv *env 




, j ob j ect this ) 


{ 

printf("Hola desde C\n"); 





Listado 6.5: Implementacion de un metodo nativo 



Ahora podemos compilar la librerfa de enlace dinamico: 

$ gcc HolaNativo.c -dynamiclib -o libHolaNativo . dylib 

Observe que el nombre de la librerfa debe ser el mismo que dimos a system. 

loadLibrary () , perO precedido por lib. 

Por ultimo, suponiendo que la librerfa de enlace dinamico este en un 
directorio accesible por la librerfa (por ejemplo el mismo directorio que la 
clase) podemos ejecutar el programa Java en una maquina virtual asf: 

$ gij HolaNativo 

Hola desde C 









boolean 


jboolean 


8 bits sin signo. 


byte 


jbyte 


8 bits con signo. 


char 


j char 


16 bits sin signo. 


short 


j short 


16 bits con signo. 


int 


j int 


32 bits con signo. 


long 


j long 


64 bits con signo. 


float 


j float 


32 bits formato IEEE. 


double 


j double 


64 bits formato IEEE. 


boolean 


jboolean 


8 bits sin signo. 



Tabla 6.1: Tipos de datos fundamentals Java y su declaracion correspondiente en C 



Pag 116 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 

2.2. Tipos de datos en JNI 

Los tipos de datos de C y Java son parecidos pero no son exactamente los 
mismos. En el fichero jni.h encontramos definidos los tipos de datos Java 
mediante typedef . La Tabla 6.1 resume estos tipos de datos. 

2.3. Pasar parametros a un metodo nativo 

Como con cualquier otro metodo Java, es posible pasar argumentos y 
retornar valores de metodos nativos. 

Por ejemplo, si tenemos una clase como la del Listado 6.6 con el metodo 
nativo sumao con parametros y retorno, al igual que antes, podemos 
obtener el prototipo del metodo nativo en C con solo compilar la clase Java y 
usar gcjh para generar el prototipo de la funcion C del metodo nativo: 

$ gcj -C SumaNativa . j ava 
$ gcjh -jni SumaNativa 
$ cat SumaNativa.h 



JNIEXPORT jint JNI CALL Java_SumaNativa_suma (JNIEnv *env, 
jobject, jint, jint); 

Observese que ademas de los dos parametros que siempre tiene la funcion 
del metodo nativo, tiene otros dos parametros de tipo jint, y tambien 
retorna un jint. 



/* SumaNativa . j ava */ 

public class SumaNativa 
{ 

static { 

System . loadLibrary ( "SumaNativa . dylib" ) ; 
} 

public static void main ( String [ ] args) 
{ 

SumaNativa s = new SumaNativa () ; 

System. out. println ("3+4=" + s . suma ( 3 , 4 ) ) ; 

} 

public native int suma(int a, int b) ; 
Listado 6.6: Clase Java con parametros en un metodo nativo 

Ahora podemos implementar el metodo nativo tal como muestra el Listado 
6.7, y generar la librerfa de enlace dinamico correspond iente con el comando: 

$ gcc SumaNativa. c -dynamiclib -o libSumaNativa . dylib 
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Por ultimo, al igual que antes, podemos ejecutar el programa Java con 
metodo nativo: 

$ gij SumaNativa 

3 + 4=7 



/* SumaNativa . h */ 
#include <jni.h> 
#include "SumaNativa . h" 

j int JNICALL Java_SumaNativa__suma (JNIEnv *env, jobject this, 

jint a, jint b) 

{ 

jint total = a+b; 
return total; 

_J 

Listado 6.7: Implementacion de un metodo nativo con parametros 



2.4. Acceso a clases Java desde un metodo nativo 

Aunque un programa Java puede instanciar una maquina virtual y ejecutar 
desde ella clases Java, en este tutorial no vamos a explicar como se hace 1 . Lo 
que si vamos a explicar es como, un metodo nativo, que ha sido ejecutado 
desde un programa Java, puede volver a acceder a la clase Java que le llamo. 



/* Teclado.Java */ 

public class Teclado 
{ 

static { 

System . loadLibrary ( "Teclado . dylib" ) ; 

} 

public static void main ( String [ ] args) 
{ 

Teclado t = new Teclado (); 

System . out . print ( "Escriba un numero:"); 

t . leeNumero ( ) ; 

} 

// Metodo nativo 

public native void leeNumero () ; 
// Metodo callback 
public void leidoNumero ( int n) 
{ 

System . out . println ( "El numero leido es " + n) ; 

} 

} 

Listado 6.8: Clase Java con un metodo nativo que llama a un metodo callback de la clase 



1 Para saber como se hace esto puede consultar el "Tutorial de JNI" publicado en 

macprogramadores . org 
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Como ejemplo usaremos la clase Java del Listado 6.8 la cual dispone del 
metodo nativo 1 eeNumero O, el cual, cuando lee un numero, llama al metodo 

Java leidoNumero ( ) . 

El Listado 6.9 muestra la implementacion del metodo nativo. El metodo nativo 
llama a la funcion JNI Getobjectciass o para obtener un puntero a la clase 
del objeto al que pertenece el metodo (apuntado por this). Despues, usando 
la funcion JNI GetMethodio o obtiene el metodo callback leidoNumero o, 
que es el metodo Java al que queremos llamar desde C. Por ultimo utiliza la 
funcion JNI caiivoidMethod o para llamar al metodo Java. 

La funcion GetMethodiD ( ) , ademas del nombre del metodo, necesita 
conocer sus parametros, ya que en Java existe la sobrecarga. Para ello utiliza 
una signatura inventada por JNI consistente en indicar entre parentesis los 
tipos de los parametros, y despues indicar el tipo de retorno. " (i)v M significa 
que el metodo recibe un ±nt y que devuelve void. Puede consultar la 
documentacion de referenda de esta funcion para aprender mas sobre las 
signaturas. 



/* Teclado.h */ 



#include <jni.h> 
#include "Teclado.h" 



JNIEXPORT void JNI CALL Java_Teclado_leeNumero (JNIEnv *env 

, j ob j ect this ) 

{ 

jclass clase = (*env) ->GetOb j ectClass (env, this) ; 
jmethodID id = 

(*env) ->GetMethodID (env, clase, "leidoNumero", " (I) V") ; 

if (id==0) 
{ 

printf ( "Metodo leidoNumero ( ) no encontrado" ) ; 
return; 

} 

int numero; 

int ret = scant ( "%i" , Snumero) ; 
if (ret!=0) 

(*env) ->CallVoidMethod (env, this, id, numero) ; 
else 

printf ( "Numero no valido\n"); 



Listado 6.9: Metodo nativo que llama a un metodo Java 



Por ultimo, podemos compilar el programa Java y la librerfa nativa con: 

$ gcj -C Teclado.java 
$ gcjh -jni Teclado 

$ gcc Teclado. c -dynamiclib -o libTeclado . dylib 
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Y ejecutar el programa que hemos hecho con: 

$ gij Teclado 

Escriba un numero:4 
El numero leido es 4 
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Tema 7 

Depuracion, 
optimizacion y 

perfilado 



Sinopsis: 



A estas alturas el lector ya sabra manejar las herramientas de GNU para 
generar programas. 

Para terminar este tutorial pretendemos estudiar las habilidades del titulo de 
este ultimo tema: Como se hace para depurar las aplicaciones cuando no se 
comportan de acuerdo a nuestros objetivos. Como pedir a las GCC que 
optimicen el codigo generado. Como detectar la corruption y perdida de 
memoria. Y como perfilar el codigo, es decir, como detectar cuellos de botella 
en trozos del programa que si optimizamos podemos conseguir un programa 
mucho menos avido de recursos, y en consecuencia mas agradable de usar. 
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1. Depurar aplicaciones 



En este primer apartado aprenderemos a usar el comando gdb (GNU 
Debugger) para depurar una aplicacion generada con las GCC. 

1.1. Generar codigo depurable 

Para generar codigo depurable debemos usar la opcion -g tanto durante la 
compilacion como durante el enlazado de la aplicacion. A esta opcion se la 
puede preceder por un nivel de informacion de depuracion de acuerdo a la 
Tabla 7.1. Si no se indica nivel, por defecto se usa -g2. 



Nivel 


Description 


l 


Este nivel incluye la minima cantidad de informacion de depuracion en 
el fichero de codigo objeto. La informacion es suficiente para trazar 
las llamadas a funciones y examinar el valor de las variables globales, 
pero no hay informacion que relacione el codigo ejecutable con el 
fuente, ni informacion que nos permita evaluar las variables locales. 


2 


Este es el nivel por defecto. Incluye toda la informacion del nivel 1, 
junto con informacion que relaciona el codigo objeto con el fuente, y 
informacion sobre los nombres y posiciones de las variables locales. 


3 


Este nivel incluye toda la informacion del nivel anterior, y ademas 
anade informacion sobre la definicion de los macros del 
preprocesador. 



Tabla 7.1: Niveles de informacion de depuracion 



1.2. Cargar un programa en el depurador 

Supongamos que tenemos el programa del Listado 7.1, el cual al irlo a 
ejecutar curiosamente falla: 

$ gcc f ibonacci . c -o f ibonacci 
$ . /f ibonacci 4 

Bus error 

Si ojeando el programa no encontramos ninguna razon para que falle, vamos 
a necesitar depurarlo. Para ello introducimos informacion de depuracion sobre 
el programa en el codigo ejecutable (usando la opcion -g) y lo cargamos en 
el depurador con los comandos: 

$ gcc f ibonacci . c -g -o f ibonacci 
$ gdb fibonacci 4 

(gdb) 



Pag 122 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 



Tras ejecutar el depurador obtenemos el prompt (gdb) donde para ejecutar 
el programa podemos escribir el comando run, el cual iniciaza la ejecucion del 
programa: 

( gdb ) run 

Starting program: ./fibonacci 

Reading symbols for shared libraries . done 

Indique un numero como argumento 

Program exited normally. 

Nuestro programa esta disenado para recibir como argumento el numero de 
Fibonacci a calcular (vease Listado 7.1). Debido a que no hemos suministrado 
este argumento, nuestro programa acaba con un mensaje donde se indica 
que no se ha recibido este argumento. 

Puede abandonar el depurador con el comando quit: 

(gdb) quit 



/* buclefor.c */ 

#include <stdio.h> 

int Fibonacci ( int n) 
{ 

if (n<=l) 

return 1; 

return Fibonacci (n-1) +Fibonacci (n-2) ; 

} 

int main (int argc, char* argv [ ] ) 
{ 

if (argc!=2) 
{ 

printf (" Indique un numero como argumento") ; 
return 0; 

} 

int n; 

sscanf (argv [ 1 ] , "%n" , &n) ; 
int sol = Fibonacci (n) ; 

printf ("El fibonacci de %n es %n\n" , n, sol) ; 
return 0; 

} 



Listado 7.1: Programa C defectuoso 

Es importante recordar que para pasar argumentos a un programa no 
podemos hacer: 
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$ gdb fibonacci 4 

. /4: No such file or directory. 

Unable to access task for process-id 4: (os/kern) failure, 
(gdb) 

Ya que en este caso gdb interpreta el argumento del programa a depurar 
como un argumento de gdb. 

Para pasar argumentos al programa a depurar debemos usar la opcion -- 
args de gdb. Esta opcion se debe poner siempre en ultimo lugar, ya que 
detiene la interpretacion de opciones por parte de gdb, y todo lo que 
pongamos detras de esta opcion se considera el nombre del programa a 
depurar y los argumentos del este. 

$ gdb --args fibonacci 4 

(gdb) 

Ahora podemos ejecutar el programa fibonacci con argumentos: 

( gdb ) run 

./fibonacci 4 

Reading symbols for shared libraries . done 

Program received signal EXC_BAD_ACCESS , Could not access 
memory . 

Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 
0x9000d3e4 in vf print f $LDBL12 8 () 

La ejecucion con run nos da algo mas de informacion. Parece ser que se ha 
producido un acceso a la direccion de memoria 0, el cual ha activado la senal 
exc bad access. Ademas gdb nos informa de que el problema se ha 
producido en la funcion printf o . De hecho el problema se debe al comun 
error de los programadores de usar %n (el parametro es un puntero a entero) 
en vez de %i (el parametro es un entero). De hecho si hubieramos usado la 
recomendable opcion -wail hubieramos descubierto antes este error: 

$ gcc fibonacci . c -g -o fibonacci -Wall 

fibonacci. c: In function 'main': 

f ibonacci . c : 27 : warning: format ' %n ' expects type ' int *', but 
argument 2 has type 'int' 

f ibonacci . c : 27 : warning: format ' %n ' expects type 'int *', but 
argument 3 has type 'int' 

Corregido este error descubrimos que el programa anterior todavfa no 
funciona correctamente: 

$ gcc fibonacci . c -g -o fibonacci -Wall 
$ . /fibonacci 4 

El Fibonacci de 0 es 1 



Pag 124 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 



Vemos que el programa responde que la posicion 0 de la sucesion de 
Fibonacci es 1, cuando lo que le hemos preguntado es cual es la cuarta 
posicion. Luego vamos a necesitar volver a ejecutar el depurador. 

En este caso vamos a ejecutar el programa a depurar paso a paso para ver 
como se Mega a este extrano resultado. 

$ gdb --args fibonacci 4 

(gdb) 

Lo primero que vamos a hacer es ejecutar el comando list el cual nos 
muestra 10 Ifneas del codigo fuente asociado al programa desde la posicion 
donde estemos, o desde el principio del fichero si no ha comenzado su 
ejecucion: 

(gdb) list 

5 int Fibonacci ( int n) 

6 { 

7 if (n<=l) 

8 return 1; 

9 return Fibonacci (n-1 ) +Fibonacci (n-2 ) ; 

10 } 



Al comando list tambien le podemos dar como argumento un numero de 
Ifnea a partir de la cual queremos listar. En este caso tambien listarfa 10 
Ifneas. Otra opcion es darle al comando list dos numeros separados por 
coma como argumento para indicar la primera y ultima Ifnea a listar. 

(gdb) list 5,20 

5 int Fibonacci ( int n) 

6 { 

7 if (n<=l) 

8 return 1; 

9 return Fibonacci (n-1 ) +Fibonacci (n-2 ) ; 

10 } 



11 
12 
13 
14 



int main (int argc, char* argv [ ] ) 



if (argc!=2) 



(gdb) 



11 
12 
13 
14 
15 
16 
17 
18 
19 
20 



int main (int argc, char* argv [ ] ) 



if (argc!=2) 



int n; 

sscanf (argv [ 1 ] , "%n" , &n) ; 



printf ( " Indique un numero como argumento"); 
return 0; 
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1.2.1. Breakpoints y depuracion paso a paso 

Debido a que run ejecuta el programa todo seguido hasta el final, lo que 
vamos a hacer es poner un breakpoint al principio de la funcion main o . Para 
ello usaremos el comando break, el cual nos permite poner un breakpoint en 
un determinado numero de Ifnea o nombre de funcion. En este caso vamos a 
poner un breakpoint en la funcion main o y otro en la funcion Fibonacci o : 

(gdb) break main 

Breakpoint 1 at 0x29bc: file fibonacci.c, line 14. 
(gdb) break Fibonacci 

Breakpoint 2 at 0x2934: file fibonacci.c, line 7. 

Podemos consultar los breakpoints fijados con el comando info 

breakpoints : 

(gdb) info breakpoint 

N Type Disp En Address 

1 breakpoint keep y 0x000029bc in main at f ibonacci . c : 14 

2 breakpoint keep y 0x00002934 in Fibonacci at f ibonacci . c : 7 

O bien eliminar un breakpoint con el comando clear que borra el breakpoint 
cuyo numero de Ifnea o nombre de funcion especifiquemos. Por ejemplo, para 
borrar el breakpoint que hemos puesto en la funcion Fibonacci o podemos 
usar: 

(gdb) clear 7 
Deleted breakpoint 2 

Una vez puesto el breakpoint en main o podemos iniciar la ejecucion de la 
funcion hasta el breakpoint de la funcion main o ejecutando el comando run: 

( gdb ) run 

Starting program: ./f ibonacci 4 

Reading symbols for shared libraries . done 

Breakpoint 1, main (argc=2, argv=0xbf f f f 994 ) at f ibonacci . c : 14 
14 if (argc!=2) 

Y luego podemos inspeccionar el valor de la variable argc con el comando 

print: 

(gdb) print argc 
$1 = 2 

Claramente el valor recibido es el esperado, luego podemos continuar la 
ejecucion paso a paso con el comando next, el cual por defecto avanza un 
paso, aunque tambien le podemos pasar como argumento el numero de 
pasos a avanzar como argumento: 
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(gdb) next 

20 sscanf (argv [1] , "%n", &n) ; 

El comando next ejecuta la Ifnea 14, y debido a que no se cumple la 
condicion de la sentencia if, nos informa que la siguiente Ifnea que se 
ejecutara sera la 20. 

Ejecutamos un paso mas, y comprobamos si la variable n se ha inicializado 
correctamente con el valor recibido como argumento: 

(gdb) next 1 

21 int sol = Fibonacci (n) ; 
(gdb) print argv[l] 

$2 = 0xbffffa46 "4" 
(gdb) print n 
$3 = 0 

Parece ser que n no se ha inicializado con el 4 que habfa en argv[i] . De 
nuevo el problema se debe a que scanf o ha usado %n en la cadena de 
formato, en vez de %i. 

Abandonamos la ejecucion del depurador con el comando quit, corregimos el 
error, y volvemos a intentarlo: 

$ gcc f ibonacci . c -g -o f ibonacci -Wall 
$ gdb --args f ibonacci 4 

(gdb) 

Esta vez podemos fijar directamente el breakpoint en la Ifnea 21, y 
comprobamos que ahora el argumento se lee correctamente: 

(gdb) break 21 

Breakpoint 1 at 0x2a04 : file f ibonacci. c, line 21. 
( gdb ) run 

Starting program: ./f ibonacci 4 

Reading symbols for shared libraries . done 

Breakpoint 1, main (argc=2, argv=0xbf f f f 994 ) at f ibonacci . c : 2 1 
21 int sol = Fibonacci (n) ; 

(gdb) print n 
$1 = 4 

El comando next ejecutarfa la funcion Fibonacci o completamente sin 
entrar en ella paso a paso. Si lo que queremos es meternos dentro de una 
funcion podemos usar el comando step de la siguiente forma: 

(gdb) step 

Fibonacci (n=4) at f ibonacci . c : 7 
7 if (n<=l) 
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La funcion Fibonacci o es recursiva y si continuamos usando step vamos a 
irnos metiendo en las sucesivas llamadas recursivas: 

(gdb) step 

9 return Fibonacci (n-1 ) +Fibonacci (n-2 ) ; 

(gdb) step 

Fibonacci (n=3) at f ibonacci . c : 7 
7 if (n<=l) 

(gdb) step 

9 return Fibonacci (n-1 ) +Fibonacci (n-2 ) ; 

(gdb) step 

Fibonacci (n=2) at f ibonacci . c : 7 
7 if (n<=l) 



Podemos ver el estado de la pila junto con el valor de los parametros en cada 
llamada con el comando where: 



( gdb ) where 

#0 Fibonacci (n=2) at f ibonacci . c : 7 

#1 0x0000295c in Fibonacci (n=3) at f ibonacci . c : 9 

#2 0x0000295c in Fibonacci (n=4) at f ibonacci . c : 9 

#3 0x00002al0 in main (argc=2, argv=0xf994) at f ibonacci . c : 2 1 

Tambien podemos retornar de una llamada a una funcion con el comando 

finish: 



(gdb) finish 

Run till exit from #0 Fibonacci (n=2) at f ibonacci . c : 7 
0x0000295c in Fibonacci (n=3) at f ibonacci . c : 9 
9 return Fibonacci (n-1 ) +Fibonacci (n-2 ) ; 

Value returned is $1 = 2 
(gdb) where 

#0 0x0000295c in Fibonacci (n=3) at f ibonacci . c : 9 

#1 0x0000295c in Fibonacci (n=4) at f ibonacci . c : 9 

#2 Ox00002alO in main (argc=2, ar gv= 0 xbf f f f 9 9 4 ) at 

f ibonacci . c : 2 1 



Vemos que hemos retornado de una llamada recursiva. Usando finish 
podemos retornar del resto de llamadas recursivas, pero si se han producido 
muchas quiza serfa mejor idea fijar un breakpoint temporal, que es un 
breakpoint que una vez que se detiene una vez el depurador en el se borra. 
En nuestro caso vamos a fijar el breakpoint temporal al acabar la primera 
llamada a Fibnonacci o, y para ello usaremos el comando tbreak: 



(gdb) list 



16 printf ( " Indique un numero como argumento" ) ; 

17 return 0; 

18 } 

19 int n; 

20 sscanf (argv [1] , "%i", &n) ; 

21 int sol = Fibonacci (n) ; 

22 printf ("El Fibonacci de %i es %i\n" , n, sol) ; 
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23 return 0; 

24 } 

(gdb) tbreak 22 

Breakpoint 2 at 0x2al8: file fibonacci.c, line 22. 

Para continuar la ejecucion no debemos de ejecutar el comando run, ya que 
este inicia la ejecucion del programa desde el principio, sino que debemos 

USar continue: 
( gdb ) run 

The program being debugged has been started already. 
Start it from the beginning? (y or n) n 
Program not restarted, 
(gdb) continue 
Continuing . 

Breakpoint 2, main (argc=2, argv=0xbf f f f 994 ) at f ibonacci . c : 22 
22 printf("El Fibonacci de %i es %i\n" , n, sol) ; 

Logicamente, tras alcanzar el breakpoint este se elimina automaticamente: 

(gdb) info break 

N Type Disp En Address 

1 breakpoint keep y 0x00002a04 in main at f ibonacci . c : 2 1 
breakpoint already hit 1 time 

Finalmente el programa parece correctamente depurado: 

(gdb) print sol 
$1 = 5 

Una facilidad de gdb que todavfa no hemos comentado es que podemos 
ejecutar una funcion de la imagen que estamos depurando usando el 
comandos can: 

(gdb) call (int) Fibonacci (6) 

$2 = 13 

Para terminar podemos abandonar la ejecucion: 

(gdb) quit 

El Listado 7.2 muestra como quedarfa el programa del ejemplo despues de 
corregir los errores encontrados. 



/* fibonacci.c */ 

#include <stdio.h> 

int Fibonacci ( int n) 
{ 

if (n<=l) 
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return 1; 

return Fibonacci (n-1) +Fibonacci (n-2) ; 



int main(int argc, char* argv [ ] ) 
{ 

if (argc!=2) 
{ 

printf ( " Indique un numero como argumento") ; 
return 0; 

} 

int n; 

s scant (argv [ 1 ] , "%i" , &n) ; 
int sol = Fibonacci (n) ; 

printf ("El Fibonacci de %i es %i\n" , n, sol) ; 
return 0; 



Listado 7.2: Programa a depurar despues de corregir los errores encontrados. 



1.2.2. Otros comandos de depuracion 

Podemos usar el comando help de gdb para obtener ayuda. Si emitimos el 
comando help sin argumentos nos indica como podemos obtener 
globalmente ayuda: 

(gdb) help 

List of classes of commands: 
aliases -- Aliases of other commands 

breakpoints -- Making program stop at certain points 
data -- Examining data 

files -- Specifying and examining files 

internals -- Maintenance commands 

obscure -- Obscure features 

running -- Running the program 

stack -- Examining the stack 

status -- Status inquiries 

support -- Support facilities 

tracepoints -- Tracing of program execution without stopping 
the program 

user-defined -- User-defined commands 

Type "help" followed by a class name for a list of commands in 
that class. 

Type "help" followed by command name for full documentation. 
Command name abbreviations are allowed if unambiguous. 

Vemos que a help le podemos pasar un conjunto de clases en las que se 
agrupan los comandos por funcionalidad (p.e. la clase stack agrupa 
comandos relacionados con inspeccionar la pila), o bien un nombre de 
comando, en cuyo caso nos describe su funcionalidad. 
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Un facilidad bastante usada de gdb es que no es necesario escribir el nombre 
completo del comando mientras que no exista ambiguedad, por ejemplo, en 
vez de escribir el comando run, podemos escribir solo r, o en vez de escribir 

info breakpoints podemOS escribir SOlO i b. 

Otra facilidad es que si pulsamos intra sin escribir comando se ejecuta el 
ultimo comando ejecutado. Lo cual es bastante util, por ejemplo, cuando 
estamos ejecutando un programa paso a paso, ya que solo es necesario 
escribir una vez el comando next (o su abreviatura n) para que las demas 
veces avance paso a paso con solo volver a pulsar intra. 



Actualmente gdb tiene cientos de comandos, la Tabla 7.2 resume los 
principales comandos de gdb. 



Comando 


Description 


awatch 


Pone un watchpoint a una variable de forma que siempre 
que se lea o escriba esta variable se detiene la ejecucion. 
Vease tambien los comandos rwatch y watch. 


break 


Fija un breakpoint en el numero de Ifnea o funcion dada. 


clear 


Borra el breakpoint en el numero de Ifnea o nombre de 
funcion dados. 


continue 


Continua la ejecucion despues de parar debido a un 
breakpoint o a un watchpoint. 


Ctrl+C 


Detiene el programa como si hubiera un breakpoint en el 
punto por el que esta ejecutandose. 


disable 


Deshabilita un breakpoint cuyo numero se da como 
argumento. 


display 


Muestra el valor de una expresion cada vez que la ejecucion 
del programa se detiene en un breakpoint o watchpoint. 


enable 


Habilita el breakpoint cuyo numero pasamos como 
argumento. 


finish 


Continua la ejecucion del programa que estamos depurando 
hasta acabar la funcion en la que nos encontremos. 


ignore 


Permite que un breakpoint se ignore un determinado 
numero de veces. Por ejemplo ignore 423 pide que el 
breakpoint numero 4 sea ignorado 23 veces antes de volver 
a detenerse en el. 


info 

breakpoints 


Muestra todos los breakpoints, asf como su estado 
(habilitado/deshabilitado/ignorado). 


info 

watchpoint 


Muestra los watchpoint, las variables a las que estan 
asignados, y su estado. 


kill 


Mata el proceso actual. 


list 


Muestra 10 Ifneas de codigo. Si no se dan mas argumentos 
se muestran 10 Ifneas cercanas a la posicion actual. Si se 
indica un argumento se muestran Ifneas cercanas al numero 
dado. Si se indican dos argumentos, separados por coma, 
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estamos indicando el numero de Ifnea desde el que listar, y 




el numero de Ifneas a listar. 


next 


Ejecuta el numero de Ifneas indicadas como argumento sin 
meterse dentro de las funciones. Si no se indica argumento, 
por defecto se avanza una Ifnea. 


print 


Imprime el valor de una variable o expresion. 


ptype 


Imprime el tipo de una variable. 


return 


Fuerza el retornar inmediatamente de una funcion sin 
terminar de ejecuta rla. 


run 


Empieza la ejecucion del programa desde el principio. Si el 
programa ya se esta ejecutando detiene su ejecucion para 
volverla a comenzar. 


rwatch 


Pone un watchpoint a una variable de forma que el 
programa solo se detiene cuando la variable es lefda (no 
cuando es escrita). Vease tambien los comandos awatch y 

watch. 


set 


Permite modificar el valor de una variable durante la 
ejecucion de un programa. Por ejemplo set soi=i2 
cambiarfa el valor de la variable sol. 


step 


Ejecuta el numero de Ifneas indicadas como argumento 
metiendose dentro de las funciones que tengan informacion 
de depuracion. Si no se indica argumento, por defecto se 
avanza una Ifnea. 


tbreak 


Pone un breakpoint temporal en la Ifnea o nombre de 
funcion indicados como argumento. 


watch 


Pone un watchpoint a una variable de forma que solo se 
detiene cuando la variable es escrita (no cuando es lefda). 
Vease tambien los comandos awatch y watch. 


whatis 


Imprime el tipo y valor de una variable. 



Tabla 7.2: Comandos mas comunes de gdb 



1.3. Analisis postmortem de un programa 

En los sistemas UNIX, cuando un programa casca se ejecuta una funcion del 
sistema operativo que hace un volcado a disco (dump) del contenido de la 
memoria en el momento de fallar el programa, produciendo lo que tambien se 
llama un fichero de core. 

Los ficheros de core son muy utiles cuando creamos aplicaciones beta que 
entregamos a los usuarios, ya que si la aplicacion inexplicablemente falla 
podemos pedir al usuario que nos reporta el problema, que nos envfe el 
fichero de core para reconstruir la escena. 
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Esta opcion no siempre esta activada por defecto, por ejemplo en Mac OS X 
por defecto esta desactivada. Para comprobar si la opcion de dump esta 
activada podemos usar el comando: 

$ ulimit -c 

0 

Esta opcion nos indica el tamano maximo del fichero de core. Si es 0 significa 
que esta desactivada la opcion. Podemos activarla pasando un valor distinto 
de 0, o el valor unlimited para indicar que el fichero de core puede medir 
todo lo que queramos 1 . 

$ ulimit -c unlimited 
$ ulimit -c 

unlimited 



/* defectuoso.c */ 
#include <stdio.h> 
char** Nada; 

void FuncionDef ectuosa ( ) 
{ 

printf ("%n\n",Nada) ; 

} 

int main ( ) 
{ 

FuncionDef ectuosa ( ) ; 
return 0; 

\ 

Listado 7.3: Programa defectuoso 

Una vez activamos esta opcion lo que necesitamos es un programa que falle, 
como por ejemplo el del Listado 7.3. Cuando ejecutamos este programa 
obtenemos la salida: 

$ gcc defectuoso . c -g -o defectuoso 
$ . /defectuoso 

Bus error 

Si activamos la opcion de generar dump y volvemos a ejecutar el programa: 

$ ulimit -c unlimited 
$ . /defectuoso 

Bus error (core dumped) 



1 En Mac OS X, con el fin de poder hacer dump de aplicaciones que no sean de consola, 
tambien podemos poner la opcion coredumps=-no- del fichero /etc/hostconf ig al valor 

COREDUMPS=-YES-. 
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Ahora Mac OS X genera un fichero de core en la carpeta /cores: 

$ Is -1 /cores 

total 96048 

-r 1 fernando admin 49176576 Feb 26 22:04 core. 645 

Supongamos que un usuario nos ha reportado este fichero de core, todo lo 
que tenemos que hacer para depurarlo es habernos acordado de compilar el 
programa con la opcion -g con el fin de que tenga sfmbolos de depuracion y 
podamos cargar ahora el fichero de core en gdb. Para ello debemos de pasar 
a gdb tanto el nombre del ejecutable como el del fichero de core. Una rapida 
inspeccion con los comandos where y list de gdb nos permite identificar el 
punto donde la aplicacion fallo. 

$ gdb defectuoso /cores/core . 645 

Core was generated by './defectuoso'. 

#0 0x9000d3e4 in vf print f $LDBL12 8 () 

(gdb) where 

#0 0x9000d3e4 in vf print f $LDBL12 8 () 

#1 0x900ff038 in vfprintf_l$LDBL128 () 
#2 0x90101674 in printf $LDBL12 8 () 

#3 0x00002af4 in FuncionDef ectuosa () at defectuoso . c : 9 
#4 0x00002b20 in main () at defectuoso . c : 14 
(gdb) list 



5 char** Nada; 

6 

7 void FuncionDef ectuosa ( ) 

8 { 

9 printf ("%n\n", Nada) ; 

10 } 
11 

12 int main ( ) 

13 { 

14 FuncionDef ectuosa () ; 



(gdb) 

1 .4. Enlazar el depurador con una aplicacion en 
ejecucion 

La herramienta gdb dispone de la posibilidad de enlazar con una aplicacion en 
ejecucion. Esto puede resultar muy util para depurar aplicaciones que 
transcurrido un tiempo fallan inesperadamente, o donde solo conseguimos 
reproducir una situacion anomala cuando ejecutamos la aplicacion sin 
depuracion 1 . 



1 Este tipo de problemas se plantean muy a menudo en aplicaciones de tiempo real, donde la 
decision de tomar un camino o otro depende del tiempo que tarde la aplicacion en ir de un 
punto del programa a otro. 
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El Listado 7.4 muestra un programa que solo se bloquea cuando escribimos el 
comando bi oquear se. Para demostrar como gdb puede enlazar con este 
programa vamos a ejecutar primero el programa: 

$ . /bloqueable 

Escriba un comando (bloquearse/salir/otro) rbloquearse 

Y ahora desde otra consola vamos a enlazar con el desde el depurador. Para 
ello gdb, ademas del nombre del programa, necesita recibir el PID del 
programa con el que enlazar (que obtendremos con el comando ps). A partir 
de este momento podemos depurar el programa como normalmente, e 
identificar la causa del bloqueo: 

$ ps 

PID TT STAT TIME COMMAND 

687 pi Ss 0:00.32 -bash 

901 pi R+ 1:49.13 ./bloqueable 

907 p2 Ss 0:00.09 -bash 

$ gdb bloqueable 901 

Attaching to program: 'bloqueable', process 901. 
Reading symbols for shared libraries . done 
Bloqueate () at bloqueable . c : 6 
6 while ( 1 ) ; 

(gdb) 



/* bloqueable. c */ 

#include <stdio.h> 

void Bloqueate () 
{ 

while ( 1 ) ; 

} 

int main ( ) 
{ 

char cmd[255] = ""; 
while (strcmp (cmd, "salir") ) 
{ 

printf ( "Escriba un comando (bloquearse/salir/otro) : " ) ; 
scant ("%s", cmd) ; 
if (! strcmp (cmd, "bloquearse" ) ) 
Bloqueate ( ) ; 

} 

return 0; 

} 

Listado 7.4: Programa que se mete en un bucle infinite 
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2.0ptimizaci6n 



Aunque podemos generar codigo optimizado (opcion -o) y con depuracion 
(opcion -g), normalmente el combinar ambas opciones da lugar a un 
programa que se comporta de forma extrana cuando lo depuramos debido a 
las optimizaciones. En general la opcion de depuracion -g se deberfa usar 
solo mientras estemos implementando el programa, mientras que la opcion 
de optimizacion -o se aconseja usar solo cuando hayamos acabado el 
programa y queramos distribuirlo. 

2.1. Opciones de optimizacion 

En este apartado vamos a empezar comentando cuales son las opciones de 
gcc que activan los diferentes niveles de optimizacion. En los siguientes 
apartados describiremos con mas detalle dos de estas tecnicas: Scheduling y 
deshacer bucles. 

El comando gcc proporciona cuatro niveles de optimizacion (del 0 al 3) que 
permiten indicar aspectos tales como las preferencias entre un codigo mas 
optimizado a cambio de mayor tiempo de compilacion, o el balanceo entre 
velocidad de ejecucion y tamano de programa 1 . Ademas, veremos que existen 
otras opciones que nos permiten controlar otros aspectos de la optimizacion. 

Las opciones dedicadas a la optimizacion del comando gcc son las siguientes: 

-oo 

Esta es la opcion por defecto cuando no se indica ninguna opcion de 
optimizacion, y lo que hace la opcion es indicar que no queremos 
optimizacion. Ademas esta es la opcion que se recomienda cuando 
vamos a depurar un programa, ya que se evitan efectos extranos en la 
depuracion al ir avanzando por el programa paso a paso. 

-oi (6 -o) 

Esta es la forma mas comun de optimizacion, y tambien se puede 
activar con -o sin indicar nivel de optimizacion. La opcion activa todas 
las optimizaciones excepto el scheduling, y las optimizaciones que 
requieran aumentar el tamaho del programa generado. Con esta 
opcion normalmente el programa copilado es menor al generado con - 
oo, e incluso el programa puede compilar mas rapido debido a que 
esta opcion hace que el backend del compilador necesite procesar 
menos datos. 



1 Debido a que es muy comun que un codigo mas rapido tambien necesite consumir mas 
memoria RAM (pero no necesariamente ocupar mas espacio su imagen en disco). 
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-02 

Esta opcion ademas de activar las optimizaciones de -01 activa la 
optimizacion por scheduling, aunque sigue sin realizar optimizaciones 
que aumenten el tamano del ejecutable. El introducir la optimizacion 
por scheduling hace que el tiempo necesario para generar el ejecutable 
aumente considerablemente. En general, esta es la mejor opcion para 
las versiones release, ya que proporciona maxima optimizacion sin 
aumentar el tamano del ejecutable. De hecho, este es el nivel de 
optimizacion que suelen usar los paquetes GNU. 

-03 

Esta opcion activa optimizaciones que pueden aumentar el tamano del 
ejecutable generado (p.e. expandir funciones inline). Normalmente 
estas optimizaciones aumentan la velocidad de ejecucion si se dispone 
de memoria RAM suficiente, pero tambien pueden hacer al programa 
mas lento. En general esta optimizacion se recomienda solo para 
funciones muy frecuentemente usadas. 

-Os 

Esta opcion activa todas las opciones de -02 mas aquellas tendientes a 
reducir el tamano del ejecutable (aunque el tiempo de ejecucion 
pudiera amentar). El uso de esta opcion puede hacer que se produzca 
codigo mas lento, pero tambien puede resultar mas rapido debido a 
que carga mas rapido y se utiliza mejor la cache. 

-fun roll-loops 

Esta opcion activa el loop unrolling (deshacer bucles) con lo que 
produce ejecutables mas grandes. En general esta opcion no es 
recomendable, sino que su uso dependera de cada caso. 



2.2. Scheduling 

La segmentacion (pipelines) es un tecnica usada por los 
microprocesadores mas avanzados (la mayorfa de los procesadores actuales: 
Pentium, SPARC, PowerPC, Alpha, ...) por la cual se solapa la ejecucion de 
varias instrucciones contiguas en el programa. Para poder ejecutar varias 
instrucciones en paralelo es necesario que las instrucciones maquina del 
programa esten colocadas de forma que una instruccion no tenga que esperar 
a que acaben las anteriores, para lo cual muchas veces es necesario que el 
compilador reordene las instrucciones maquinas convenientemente. El 
scheduling es la tecnica usada para reordenar estas instrucciones por parte 
del compilador. 
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2.3. Deshacer bucles 

Cuando un bucle es corto y y tiene un numero de iteraciones fijas, como por 
ejemplo: 

for (int i=0;i<8;i++) 



El bucle gasta mas tiempo en comprobar la condicion de repeticion y en 
actualizar el contador que en realizar la operacion del cuerpo del bucle. 

En situaciones como esta conviene, desde el punto de vista de la 
optimizacion, deshacer el bucle para obtener: 
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3. Control de corrupcion y perdida de 
memoria 



Este apartado explica como podemos detectar los problemas de corrupcion y 
perdida de memoria usando una serie de herramientas que existen en OS X 
para tal fin. 

3.1. Corrupcion de memoria 

La corrupcion de memoria ocurre cuando el programa escribe datos en una 
zona de memoria distinta a la esperada. En este caso lo mejor que puede 
pasar es que el sistema operativo lo detecte y el programa sea terminado. Si 
el sistema operativo no lo detecta, este cambio acabara afectando a otro 
trozo de programa que tarde o temprano fallara. 

El error de corrupcion de memoria mas comun en C es el del 
desbordamiento de buffer, el cual ocurre cuando un programa escribe 
mas alia del trozo de memoria que tenfamos reservada para el. Por ejemplo: 

char* mi_copia = malloc ( strlen ( cadena) ) ; 

Aquf estamos escribiendo un byte mas alia del bloque de memoria reservado, 
para corregirlo deberfamos de haber reservado un byte mas para que 
pudieramos almacenar el caracter de final de Ifnea: 

char* mi_copia = malloc ( strlen ( cadena) +1 ) ; 
strcpy (mi_copia, cadena) ; 

Este tipo de errores tambien es muy tfpico que se produzca por bucles que 
dan una vuelta mas de las que deberfan: 

char digitos [10]; 
bool encontrado=f alse ; 
for (int i=0; i<=10; i++) 
digitos [i] = 'O'+i; 

Observese que el bucle se repite 11 veces, y no 10. Lo peor de todo es que el 
bucle no falla, pero modificara la variable encontrado haciendo que luego el 
programa no se comporte como esperabamos. 

Un desbordamiento en memoria dinamica reservada con maiioco puede 
provocar que el fallo se detecte mucho mas tarde, ya que maiioco 
almacena informacion de contabilidad de los bloques asignados justo delante 
del puntero que nos devuelve, con lo que si sobrescribimos esta memoria el 
problema se producira mucho mas tarde, cuando ejecutemos los free o de 
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esos bloques. Estos problemas pueden resultar extremadamente diffciles de 
detectar. 



Otro efecto lateral del desbordamiento de buferes es que podemos enviar 
mucha informacion a un programa, que no controla el tamano de sus buferes, 
para que se desborden, y escribir asf en la pila del programa, de forma que 
consigamos retornar a una determinada direccion de memoria. Esta tecnica la 
han utilizado en muchas ocasiones los hackers para burlar la seguridad de un 
sistema. 



Otra forma de corrupcion de memoria es la conocida como puntero loco, la 
cual se produce cuando la direccion de memoria a la que apunta un puntero 
no tiene relacion con la direccion de memoria a la que realmente deberfa de 
apuntar. Un ejemplo se produce cuando a un trozo de memoria lo apuntamos 
con dos punteros y no actualizamos uno de ellos. Por ejemplo: 

char* nombre_usuario; 

const char* getNombreUsuario ( ) 

{ 

return nombre_usuario; 

} 

void setNombreUsuario ( const char* nombre) 
{ 

free (nombre_usuario) ; 

nombre_usuario = strdup (nombre) ; // Realiza un malloc() 



Ahora considerese el siguiente escenario: 



nombre = getNombreUsuario () ; 
setNombreUsuario ( "Luis " ) ; 




3.2. Perdida de memoria 

La perdida de memoria se produce cuando un programador hace un 
programa que reserva memoria, con maiioc o , y olvida liberar esta memoria, 
con free ( ) , cuando el programa ya no la va a usar mas. 

Este despiste normalmente no da problemas cuando el programa que vamos 
a ejecutar tiene una vida corta, ya que el sistema operativo libera toda la 
memoria reservada por un programa una vez que este termina (o falla). En 
programas que pueden permanecer ejecutando durante semanas, meses o 
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anos (p.e. servidores) el problema se vuelve acumulativo, ya que cada vez 
que el programa pasa por un punto hace una reserva que nunca liberara 1 . 

3.3. Las malloc tools 

Para detectar estos problemas, y otros muchos problemas de memoria, las 
librerfas de reserva de memoria de Mac OS X pueden ayudarnos como vamos 
a ver a continuacion. 

Aunque a estas librerfas se las llama las malloc tools, en referenda a que es la 
funcion maiioc o la que proporciona estas ayudas de depuracion, en realizad 
se pueden usar con todos los sistemas de reserva de memoria de Mac OS X, 
como por ejemplo el operador new de C+ + . 

Para que estas librerfas nos ayuden lo unico que tenemos que hacer es fijar 
determinadas variables de entorno antes de ejecutar la aplicacion. Estas 
variables no es necesario fijarlas antes de compilar ya que es el propio 
runtime de la funcion maiioco, y no el compilador el que comprueba si 
estas variables de entorno estan fijadas, y de hecho podemos depurar 
cualquier comando o programa de Mac OS X fijando estas variables. 



Variable entorno 


Descri prion 


MallocHelp 


Muestra ayuda sobre como funcionan las 
malloc tools. 


MallocGuardEdges 


Anade dos paginas de guarda a los lados 
de cada bloque. 


Mai locDoNot Protect Prelude 


Quita la pagina de guarda anterior a los 
bloques (solo es util cuando usamos 

MallocGuardEdges). 


MallocDoNotProtectPostlude 


Quita la pagina de guarda posterior a los 
bloques (solo es util cuando usamos 

MallocGuardEdges). 


MallocScribble 


Ayuda a detectar lecturas de bloques 
liberados escribiendo 0x55 en todos los 
bytes al liberarlos. 


MallocStackLogging 


Almacenan informacion de llamada a 
rutinas para el comando 

malloc history. 


MallocStackLoggingNoCompact 


Almacenan informacion ampliada de 
llamada a rutinas para el comando 

malloc history. 



Tabla 7.3: Variables de entorno de las malloc tools 



1 Esto explica porque Windows NT 4.0 sufna un proceso degenerativo tan rapido que le hacfa 
ejecutar cada vez mas lento y que transcurrida una semana habfa que reiniciarlo para que 
volviera a funcionar a un ritmo normal. Los servicios de Windows NT 4.0 padecfan de este 
mal, y poco a poco se iban comiendo toda la memoria. 
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En la Tabla 7.3 se resumen cuales son las variables de entorno que usan las 
malloc tools. Vamos a comentar mas detalladamente como funcionan estas 
variables de entorno. 

3.3.1. Obtener ayuda 

Podemos usar la variable de entorno MaiiocHeip para que las malloc tools 
nos muestren un mensaje de ayuda cada vez que vayamos a ejecutar un 
programa indicando que variables de entorno reconoce. 

Para ver como funciona simplemente fije esta variable de entorno a cualquier 
valor. Por ejemplo, en bash hanamos: 

$ export MallocHelp=si 

Cualquier programa que ejecute ahora mostrara ayuda sobre las malloc tools: 
$ Is 

malloc [513] : environment variables that can be set for debug: 

- MallocGuardEdges to add 2 guard pages for each large block 

- MallocDoNotProtectPrelude to disable protection (when 
previous flag set) 

- MallocDoNotProtectPostlude to disable protection (when 
previous flag set) 

- MallocStackLogging to record all stacks. Tools like leaks 
can then be applied 

- MallocStackLoggingNoCompact to record all stacks. Needed for 
malloc_hi story 

- MallocScribble to detect writing on free blocks: 0x55 is 
written upon free 

- MallocCheckHeapStart <n> to check the heap from time to time 
after <n> operations 

- MaiiocHeip - this help! 

Compiladores IC Music Public Desktop Library bin Documents 
Logica Pictures Sites tmp 

Para poder depurar las aplicaciones graficas con las malloc tools, estas 
deberan de poder leer estas variables de entorno, para lo cual debera 
ejecutarlas desde la consola, por ejemplo asf: 

$ open /Applications/Mozilla . app 

Como ve, esta variable de entorno solo sirve para dar ayuda, vamos a 
comentar otras variables de entorno mas interesantes. 
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3.3.2. Detectar accesos fuera de la memoria reservada 

La variable de entorno MaiiocGuardEdges pone una pagina de memoria de 
4KB sin permisos de acceso justo delante y detras de cada bloque asignado. 
Esto permite capturar desbordamientos de buffer. La documentacion indica 
que esto solo se hace cuando se trata de bloques "grandes". Aunque no se 
especifica el valor de "grande", experimentalmente se puede comprobar que 
"grande" es cuando el bloque de memoria supera los 12KB. 

El Listado 7.5 muestra un programa Objective-C, al que hemos llamado 

maiiocguard.m que prueba esta opcion. 



/* maiiocguard.m */ 

int main ( ) 
{ 

char* memoria = (char*) malloc (1024*16) ; 
// Escribe fuera de la memoria reservada 
memoria [ (1024*16) +1] = ' x ' ; 
return 0; 

} 

Listado 7.5: Programa que escribe fuera de la memoria reservada 

Una vez compilado: 

$ gcc maiiocguard.m -o mallocguard 

Si ejecutamos el programa sin fijar MaiiocGuardEdges obtenemos: 

$ . /mallocguard 

Pero si fijamos esta variable de entorno: 

$ export MallocGuardEdges=l 
$ . /mallocguard 

malloc[548]: protecting edges 
Bus error 

Nos detecta que nuestro programa escribe fuera del bloque permitido 
produciendose un fallo de pagina. 

Para acabar comentaremos que podemos quitar las paginas de guarda 
anterior o posterior al bloque de memoria reservado usando las variables de 

entorno MallocDoNotProtectPrelude V MallocDoNotProtectPostlude. 
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3.3.3. Detectar accesos a memoria liberada 

La variable de entorno Maiiocscribbie hace que cuando se libere un bloque 
de memoria se escriba sobre todos sus bytes el valor 0x55, lo cual sirve para 
capturar intentos de utilizar ese bloque despues de haber sido liberado. 
Observese que 0x55 se ha elegido porque es un valor impar y cualquier 
intento de dereferenciar un puntero que apunte a un valor impar produce una 
excepcion (odd address), con lo que si en la estructura de memoria liberada 
hubiera alguna variable de tipo puntero que luego quisieramos utilizar se va a 
producir esta excepcion. Por desgracia, experimentalmente hemos 
comprobado que free o siempre deja los 8 primeros bytes a 0, lo cual puede 
dificultar la captura de errores. 



El Listado 7.6 muestra un ejemplo llamado maiiocscribbie. m que usa esta 
opcion. 



/* maiiocscribbie .m */ 






#import <stdlib.h> 






typedef struct 
{ 






char nombre [2 0] ; 






char apellidos [30] ; 






} Persona; 






int main ( ) 






{ 

Persona* p = malloc ( sizeof ( Persona) ) 






strcpy (p->nombre, "Fernando" ) ; 






strcpy (p->apel lidos , "Lopez " ) ; 






print f ( "Nombre : %s Apellidos : %s\n" , p- 


>nombre, p- 


->apellidos) ; 


f ree (p) ; 






print f ( "Nombre : %s Apellidos : %s\n" , p- 


>nombre, p- 


->apellidos) ; 


return 0; 

} 







Listado 7.6: Programa que detecta accesos a memoria liberada 



Al ejecutarlo obtenemos: 

$ . /maiiocscribbie 

Nombre : Fernando Apellidos : Lopez 
Nombre: Apellidos : Lopez 

Observese que free o ha sobrescrito los 8 primeros bytes con ceros, por eso 
el nombre no aparece. 

Si ahora activamos la opcion Maiiocscribbie de las malloc tools: 

$ export MallocScribble=l 
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$ . /mallocscribble 

malloc[344] : enabling scribbling to detect mods to free blocks 
Nombre : Fernando Apellidos : Lopez 

Nombre : Apellidos : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU 

Vemos que aunque free ( ) sigue dejando los primeros 8 bytes a 0, todos los 
demas quedan con un 0x55, con lo que nos ayuda a identificar que estamos 
leyendo de memoria liberada. 

3.3.4. Detectar la corrupcion de la memoria dinamica 

Las Variables de entOmO MallocCheckHeapStart y MallocCheckHeapEach 

nos permiten chequear una posible corrupcion de las estructuras internas de 
maiioc o (debido a que el programa ha escrito donde no debfa), ejecutando 
rutinas de chequeo del heap periodicamente. 

En MallocCheckHeapStart indicamos el numero de reservas de memoria 
necesarias antes de que se empiece a chequear el heap, y en 
MallocCheckHeapEach indicamos los intervalos tras los que realizar los 
chequeos. 

A medida que el programa se ejecuta se van imprimiendo mensajes como el 
siguiente, indicando que el chequeo a sido exitoso: 

MallocCheckHeap : PASSED check at 37800th operation 

Cuando se nos avisa de que las estructuras de memoria de maiioc o han 
sido alteradas podemos ajustar las variables MallocCheckHeapStart y 
MallocCheckHeapEach para ir buscando en que zona ocurre la modificacion. 

3.4. El comando leaks 

leaks es un comando que examina a un proceso en ejecucion para detectar 
buferes asignados por maiioc o que no estan referenciados por ningun 
puntero. 

Para poder comprobar las perdidas de memoria de un proceso, este debe de 
estar en ejecucion, con lo que si es necesario podemos poner un bucle infinite 
al final del programa: 

main ( ) 
{ 



while ( 1 ) ; 
return 0; 



Pag 145 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 
Por ejemplo, imaginemos que tenemos el programa del Listado 7.7: 



/* pierde.c */ 

#include <stdio.h> 

main ( ) 
{ 

char* bloquel = ( char* ) malloc ( 1024 ) ; 
printf ( "Perder memoria (s/n)?"); 
char c; 

while ( (c=getchar ( ) ) == 's' ) 
{ 

bloquel= (char* ) malloc ( 1024 ) ; 
getchar(); // Quita el '\n' 
printf ( "Perder memoria (s/n)?"); 

} 

return 0; 



Listado 7.7: Programa con fugas de memoria 

Este programa pierde memoria cada vez que asignamos un nuevo valor a 

bloquel. 

Para comprobar como el comando leaks detecta las perdida de memoria, 
primero debemos de ejecutar este programa en una consola. Suponiendo que 
el programa este en un fichero llamado pierde . c harfamos: 

$ gcc pierde . c -o pierde 
$ pierde 

Perder memoria (s/n)? 

Ahora desde otra consola miramos que numero de proceso tiene el comando 
y usamos leaks para ver si ha perdido memoria: 

$ ps 

PID TT STAT TIME COMMAND 

631 pi Ss 0:00.08 -bash (bash) 

721 pi S+ 0:00.01 pierde 

725 std Ss 0:00.03 -bash (bash) 

$ leaks -cycles 721 

Locating all 11 malloced pointers in use . . . 
Computing connected groups . . . 
Computing non-malloced pages . . . 
Enumerating all pages non-malloced . . . 

Doing the transitive closure of all reachable groups . . . 

Gathering leaks . . . 

==== 0 simple leaks 

==== 0 non circular group leaks 

==== 0 cyclic leaks 
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Vemos que inicialmente no hay ninguna perdida de memoria detectada, pero 
si ahora hacemos que pierde pierda memoria: 



Perder memoria (s/n)?s 
Perder memoria (s/n)? 



Y volvemos a ejecutar leaks: 



$ leaks -cycles 721 

Locating all 12 malloced pointers in use . . . 

Computing connected groups . . . 

Computing non-malloced pages . . . 

Enumerating all pages non-malloced . . . 

Doing the transitive closure of all reachable groups 

Gathering leaks . . . 

==== 1 simple leaks 

Leak: 0x000442b0 size=1038 

0x00000000 0x00000000 0x00000000 0x00000000 
0x00000000 0x00000000 0x00000000 0x00000000 
0x00000000 0x00000000 0x00000000 0x00000000 
0x00000000 0x00000000 0x00000000 0x00000000 
0x00000000 0x00000000 0x00000000 0x00000000 
0x00000000 0x00000000 0x00000000 0x00000000 
0x00000000 0x00000000 0x00000000 0x00000000 
0x00000000 0x00000000 0x00000000 0x00000000 

==== 0 non circular group leaks 
==== 0 cyclic leaks 



Vemos que acaba de detectar la perdida de memoria. 
3.5. El comando malloc_hi story 

maiioc history nos permite inspeccionar un proceso en ejecucion y ver las 
asignaciones de memoria que ha hecho. Para que este comando funcione 
necesitamos exportar la variable de entorno MaiiocstackLogging. Por 
ejemplo, podemos depurar nuestro anterior programa asf: 

$ export MallocStackLogging=l 
$ pierde 

malloc [7 68 ] : recording stacks using standard recorder 
Perder memoria (s/n)?s 
Perder memoria (s/n)? 



Ahora desde otra consola ejecutamos: 

$ malloc_history 768 -all_by_size 

1 calls for 131072 bytes: thread_800013b8 |0xl000 | start | 

_start | main | srget | srefill | smakebuf | malloc | 

malloc zone malloc 



Pag 147 



Compilar y depurar aplicaciones con las herramientas de programacion de GNU 

1 calls for 131072 bytes: thread_800013b8 |0xl000 | start | 

_start | main | printf | vfprintf | swsetup | smakebuf | 

malloc | malloc_zone_malloc 

1 calls for 1024 bytes: thread_800013b8 |0xl000 | start | 
_start | main | malloc | malloc_zone_malloc 
1 calls for 1024 bytes: thread_800013b8 |0xl000 | start | 
_start | main | malloc | malloc_zone_malloc 

1 calls for 72 bytes: thread_800013b8 |0xl000 | start | __start 

| keymgr_dwarf 2__register_sections | 

_dyld_register_f unc_f or_add_image | 
register_f unc_f or_add_image | 
dwarf 2_unwind_dyld_add_image_hook | 
_keymgr_get_and_lock_processwide_ptr | 

_keymgr_get_and_lock_key | _keymgr_get_or_create__key_element | 

_keymgr_create_key_element | malloc | malloc_zone_malloc 

1 calls for 36 bytes: thread_800013b8 |0xl000 | start | _start 

| keymgr_dwarf 2__register_sections | 

_dyld_register_f unc_f or_add_image | 
register_f unc_f or_add_image | 

dwarf 2_unwind_dyld_add_image_hook | calloc | 
malloc_zone_calloc 

1 calls for 18 bytes: thread_800013b8 |0xl000 | start | _start 

| keymgr_dwarf 2_register_sections | 

_dyld_register_f unc_f or_add_image | 
register_f unc_f or_add_image | 

dwarf 2_unwind_dyld_add_image_hook | calloc | 

_malloc_initialize | malloc_set_zone_name | malloc_zone_malloc 
1 calls for 8 bytes: thread_800013b8 |0xl000 | start | _start 

| keymgr_dwarf 2_register_sections | 

_dyld_register_f unc_f or_add_image | 
register_f unc_f or_add_image | 
dwarf 2_unwind_dyld_add_image_hook | 

_keymgr_get_and_lock_processwide_ptr | _init_keymgr | malloc | 
malloc_zone_malloc 

Aquf aparecen todas las llamadas a maiioc o que ha hecho nuestro proceso 
(directamente o a traves de subrutinas). 

Una utilidad de este comando es detectar accesos a bloques de memoria 
liberada, combinandolo con la variable de entorno Maiiocscribiing, la cual 
escribfa 0x55 en los buferes liberados. Si hemos intentado escribir en un 
buffer liberado, maiioc history mostrara un mensaje de advertencia 
avisandonos de tal hecho. 

3.6. MallocDebug 

Mac OS X dispone de una herramienta llamada MallocDebug . app que 
podemos encontrar en el directorio /Developer/Applications que nos 
permite depurar la memoria dinamica reservada por maiioco de forma 
grafica. Recomendamos al lector que la eche un vistazo. 
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4.Perfilado 



De todos es conocida la vieja frase: "Un programa pasa el 90% de su tiempo 
ejecutando el 10% del codigo". El objetivo del perfilado (profiling) es 
identificar este 10% del programa y optimizarlo. 

4.1. Usar el profiler gprof 

El perfilador de GNU lo implementa el comando gprof, un comando que 
resulta util a la hora de medir el rendimiento de un programa, para ello este 
programa registra el numero de llamadas que se producen a cada funcion del 
programa, y el tiempo gastado en cada una de ellas. Esto nos ayuda a 
identificar las funciones que mas tiempo gastan. Si conseguimos optimizar las 
funciones que dominan el tiempo de ejecucion, estaremos optimizando de 
forma mas inteligente nuestro programa. 

Collatz propuso la conjetura (actualmente sin demostracion conocida) de que 
cualquier numero entero positivo x n operado repetidamente por dos 
operaciones tiende a 1. Estas dos operaciones son: Si x n es impar, se 
convierte en 3x n +l. Si x n es par se convierte en x n /2, es decir 1 : 

fSi x n es impar — > 3x n +l 



El Listado 7.8 muestra un programa que comprueba la conjetura de Collatz 
con los 5.000.000 de primeros numeros naturales. Para ello llama a la funcion 
convergencia ( ) que calcula el numero de pasos necesarios para que 
convenga cada numero. La funcion convergencia ( ) a su vez llama a la 
funcion siguiente o que devuelve el siguiente numero de la serie de Collatz. 

Para usar el perfilador debemos de crear un ejecutable instrumentalizado 
para perfilacion, el cual contiene instrucciones adicionales para registrar las 
funciones llamadas y el tiempo dedicado a cada una. Para crear un ejecutable 
instrumentalizado para perfilacion debemos compilar y enlazar el programa 
con la opcion -pg: 

$ gcc -Wall -c -pg collatz. c 

$ gcc -Wall -pg collatz. o -o collatz 

Ahora ejecutarfamos el programa como normalmente: 

$ ./collatz 



1 Observe que x n =l es condicion de parada y si x n =2, x n+1 =l, la curiosidad esta en que salen 
mas pares que impares, ya que sino x n+1 =3x n +l nana que la serie tendiera a infinite 
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#include <stdlib.h> 



unsigned int siguiente (unsigned int n) 
{ 

if (n%2==l) 

n = 3*n+l; 
else 

n= n/2; 
return n; 

} 



unsigned int convergencia (unsigned int n) 
{ 

unsigned int pasos=0; 
while (n!=l) 
{ 

if (n>500000000) 
{ 

fprintf (stderr, "Error %u no converge\n" , n) ; 
exit ( 1 ) ; 

} 

n = siguiente (n) ; 
pasos++; 

} 

return pasos; 

} 

int main ( ) 
{ 

// Estudia la convergencia de los numeros de 1 a 5000000 
unsigned int i; 
for (i=l; K5000000; i + + ) 
{ 

unsigned int pasos = convergencia (i) ; 
printf("%u converge a 1 en %u pasos\n" , i, pasos ) ; 

} 



return 0; 

} 

Listado 7.8: Programa que comprueba la conjetura de Collatz 



El programa instrumentalizado segun se ejecuta va silenciosamente creando 
en el directorio actual un fichero llamado gmon . out, con informacion sobre 
las funciones ejecutadas y su tiempo de ejecucion. Podemos analizar el 
contenido de este fichero con el comando gprof, al que le debemos dar 
como argumento el nombre del programa que se estaba perfilando: 

$ gprof collatz 

cumul self self total 

%time sees sees calls ms/call ms/call name 

68.59 2.14 2.14 740343580 0.03 0.03 _siguiente 

31.09 3.11 0.97 4999999 1.94 6.22 _convergencia 
0.32 3.12 0.01 1 main 
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Observese que en principio podrfamos pensar que la funcion que mas tiempo 
esta ejecutando es maino porque desde que empieza la ejecucion del 
programa hasta que acaba siempre estamos dentro de ella, pero esto no es 
cierto, y de hecho aunque el campo cumulative sees asf lo muestra, el campo 
self sees y % time muestran solo el tiempo pasado dentro de cada funcion. 

4.2. Test de cobertura con gcov 

Los test de cobertura nos dicen cuantas veces ha sido ejecutada cada Ifnea 
del programa durante su ejecucion. Normalmente durante la etapa de 
pruebas de un software es recomendable comprobar que todas las Ifneas del 
programa son ejecutadas al menos una vez. Si se detecta que una Ifnea 
nunca se ejecuta, esta Ifnea puede ser eliminada del programa. Ademas, el 
conocer las Ifneas mas ejecutadas es util para poder perfilar el programa. 

Las GCC proporcionan el comando gcov para poder realizar test de cobertura. 
Suponiendo que partimos de nuevo del programa del Listado 7.8, para 
realizar un test de cobertura podemos compilar el programa de la forma: 

$ gec -fprof ile-arcs -f test-coverage collatz.c -o collatz 

Esto hace que el ejecutable se instrumentalice para registrar el numero de 
veces que es ejecutada cada funcion. En concreto la opcion -f test- 
coverage hace que se cuente el numero de veces que se ejecuta cada Ifnea, 
mientras que la opcion -fprof lie-arcs hace que se guarde informacion 
sobre la frecuencia con la que se toma cada rama de una instruccion de 
bifurcacion. 

Ahora debemos ejecutar el programa instrumentalizado para que se cree esta 
informacion de instrumentalizacion: 

$ ./collatz > /dev/null 

Esto hace que se generen varios ficheros en el directorio actual con 
informacion del test de cobertura. Esta informacion puede ser analizada por 
gcov, al que ademas debemos de pasar los nombres de los ficheros de codigo 
fuente: 

$ gcov collatz.c 

File 'collatz.c' 

Lines executed: 89 . 47% of 19 

collatz. crcreating 'collatz. c. gcov' 

El comando nos informa de que se ha creado el fichero collatz.c. gcov con 
esta informacion: 
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$ cat collatz.c.gcov 





0 


Source : collatz . c 




0 


Graph : collatz . gcno 


_ 


0 


Data:collatz. gcda 


- 


0 


Runs : 1 


— 


0 


Programs : 1 


— 


1 


/* collatz. c */ 


— 
— 


2 
3 


#include <stdio.h> 


— 


4 

5 


#include <stdlib.h> 


— 
— 


6 


unsigned int siguiente (unsigned int n) 


5024987 


7 


{ 


5024987 


8 


if (n%2==l) 


1665647 


9 


n = 3*n+l; 


— 


10 


else 


3359340 


11 


n= n/2; 


5024987 


12 


return n; 


- 


13 


} 


— 


14 




— 


15 


unsigned int convergencia (unsigned int n) 


49999 


16 


{ 


49999 


17 


unsigned int pasos=0; 


5124985 


18 


while (n!=l) 


— 


19 


{ 


5024987 


20 


if (n>500000000) 


— 


21 


{ 


##### 


22 


fprintf (stderr, "Error %u no con 


##### 


23 


exit ( 1 ) ; 


— 


24 


} 


5024987 


25 


n = siguiente (n) ; 


5024987 


26 


pasos++; 


— 


27 


} 


49999 


28 


return pasos; 


— 


29 


} 


— 


30 






31 


int main ( ) 


1 


32 


{ 


— 


33 


/ / Estudia la convergencia de los numeros 


- 


34 


unsigned int i; 


50000 


35 


for (i=l; K50000; i++) 




36 


{ 


49999 


37 


unsigned int pasos = convergencia (i) ; 


49999 


38 


printf("%u converge a 1 en %u pasos\n 




39 


} 




40 




1 


41 


return 0; 




42 


} 



Observe que el comando gcov nos informo de que solo se han ejecutado el 
89.47% de las Ifneas. Ademas nos marca con ##### las Ifneas que nunca se 
han ejecutado. 
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